hgm wrote:Would it be possible to get a consensus here?
If Glaurung, HIARCS and Rybka would all change to using 'Processors' in UCI, I don't think it is too late to change the 'cores' command I added to my alpha version of WinBoard into 'processors' as well, and have Polyglot translate one into the other.
Who is the de-facto authority on UCI protocol? SMK? The author of Arena?
abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
Threads is wrong for some. Processes is wrong for others. CPUs or Processors is the appropriate term. Cores should be dropped from everyone's vocabulary in this context...
Regarding Glaurung "Threads" is the correct one, CPU (or processor) is defenitly the wrong one.
I can set Glaurung to 10 threads also on a single core CPU and it will run with 10 threads.
When Glaurung speaks of threads it actually means threads that are not CPU, are not processors, are not cores and are not processes: are threads.
Interested people can easly google for definitions of the above terms in case of doubts.
IMHO an universal accepted name should asbtract the implementation detail that can (and do) change among programs and should focus on the function.
abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
Threads is wrong for some. Processes is wrong for others. CPUs or Processors is the appropriate term. Cores should be dropped from everyone's vocabulary in this context...
Regarding Glaurung "Threads" is the correct one, CPU (or processor) is defenitly the wrong one.
I can set Glaurung to 10 threads also on a single core CPU and it will run with 10 threads.
When Glaurung speaks of threads it actually means threads that are not CPU, are not processors, are not cores and are not processes: are threads.
Interested people can easly google for definitions of the above terms in case of doubts.
IMHO an universal accepted name should asbtract the implementation detail that can (and do) change among programs and should focus on the function.
I think is less wrong something like
- Nr of parallel searchers
- Parallelism count
- You name them
Marco
I agree (for what that's worth). The parameter relates to what the chess engine does to utilitize the machine it's running on; create threads. Whether each thread runs on a dedicated CPU or not is neither here nor there.
Also isn't this the tip of the iceberg when it comes to how parameters are defined with different chess engines? If the UCI is too 'thin' to specify such things then authors have free reign and all authors have chosen different names for every parameter haven't they - apart from the one or two mentioned in the UCI spec. What's the biggy?
I should have known this happens when trying to get consensus amongst engineers
It is true that the UCI spec is thin in many regards, but I just thought this particular feature is important enough to standardize (the "biggy" to me seems that tournament managers can "unify" the amount of parallelism over a large set of engines at once, just like unifying the hash size now). One could imagine going even further and, for example, define the amount of parallelism used while pondering independently in order to be "nice" to the other engine that can claim more CPU resources in its own time. But first things first.
I agree that "Parallelism" would perhaps be a proper abstraction, but don't really see any issues with "Processors" or "CPUs" either (beyond irrelevant discussions on exact definitions of all terms). After all, it is a message to the engine. So if one defines CPUs=16 on a uniprocessor, I think most users expect the engine to start 16 threads or processes or what not. I also think "cores" is indeed somewhat of a misnomer.
So, HG and others, shall we make a (futile?!) attempt at a standard and pick "Processors", or will this be met with great resistance?
abik wrote:So, HG and others, shall we make a (futile?!) attempt at a standard and pick "Processors", or will this be met with great resistance?
No! I mean yes! Uh, the first one.
I think "processors" is good. "Parallelism" or whatever is bad IMO, as it is not an accepted term and will only confuse users, while programmers will just wonder why a command has such a weird name. UCI already has enough badly named commands IMO.
The fact that "processors" actually maps to the hardware is an advantage IMO. If a user sees "parallelism", they say "Hey, parallelism is good! I'll just bump this up to 32!" when they have a single processor computer. Most users will know how many CPUs they have, and if they see this option, they will know directly what it means and what to set it as.
This also brings up a point I'd like to make about xboard protocol changes. It would be nice to have a "description" parameter so that commands that might be vague just from the name can have a longer explanation for the user. This wouldn't apply here (if "processors" is a standard command the GUI should supply the description), but for other commands it might be good...
Threads doesn't work, not all programs use threads
I know you'd say that
But processes and threads are basically the same thing. On Linux threads are created by the clone call which is a sort of fork except that all memory is (or can be) shared.
Internally everything is managed by the scheduler.
I assume that on windows it is the same.
Also, many end users won't know what threads are.
Most users don't know what CPU's are either (seriously that's true)!
abik wrote:That makes sense. I personally thought Glaurung's "Threads" was a good choice, so I am going with that one.....
Nooo! What about the programs out there that use processes?
I don't like "cores" either. Really the only term that makes sense IMO is "CPUs".
Threads is wrong for some. Processes is wrong for others. CPUs or Processors is the appropriate term. Cores should be dropped from everyone's vocabulary in this context...
Regarding Glaurung "Threads" is the correct one, CPU (or processor) is defenitly the wrong one.
I can set Glaurung to 10 threads also on a single core CPU and it will run with 10 threads.
When Glaurung speaks of threads it actually means threads that are not CPU, are not processors, are not cores and are not processes: are threads.
Interested people can easly google for definitions of the above terms in case of doubts.
IMHO an universal accepted name should asbtract the implementation detail that can (and do) change among programs and should focus on the function.
I think is less wrong something like
- Nr of parallel searchers
- Parallelism count
- You name them
Marco
EXACTLY!!
I mentioned this a little time ago. We should use an abstract name that is detached from the intricacies of hardware technicalities.
In fact, I can have two "parallel searchers" in a CPU with one core, in a quad, whatever. Sorry, but CPU, processor, cores, threads, processors, etc. is all GEEKY jargon.
abik wrote:Does the UCI protocol provide a standard way of informing the engine how many cpu's (cores if you want) it may use for an SMP implementation?
No. I asked SMK, author of UCI, the same question some weeks ago.
More precisely I asked him if there is a recommendation for such an option. He only replied that unfortunately there is no consistent ("einheitlich") solution.
