UCI protocol and SMP

[abik]

No. I asked SMK, author of UCI, the same question some weeks ago.

Ironic, I just dropped him an email myself

I am a little puzzled why this is cause for such a seemingly heated debate. It appears reasonable to me to view the UCI option like a configuration setup that tells the engine to view the machine it is running on in a particular way, such as having a certain number of processors (even if physically it has not). Similarly, I would have no major issues with referring to this as threads, even if some implementations use processes (just wait until we move to distributed computing, then we can have this discussion again).

I simply think the chess community would benefit from one standard term, whatever it is. Folks, can't we set out differences aside and agree on one tiny keyword (this is why languages should be designed by one person not committees ).

[hgm]

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.

Well, if we consider SMK to be the authority on UCI, I suppose we should consider the way that Shredder does it as the standard...

[jswaff]

Why not go ahead and lobby for two parameters: one, say "nodes" (in the # of nodes in a cluster sense), and the other "cpus" (per node). That way there is a distinction between a single machine with 32(!) cpus and a cluster of four workstations, each running 8. Of course then there is the issue of non-uniform nodes...

--
James

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?

[bob]

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?

the only UCI specification i've ever seen is available here:
http://www.shredderchess.com/chess-info ... rface.html

1 CPU is seen by Windows as 2 processors if the CPU is hyperthreading capable and enabled.
http://software.intel.com/en-us/article ... processors

and in this case i believe it's best that the engine uses 1 thread instead of 2, so perhaps CPU is a better choice?

even on a single chip multi-core machine, CPU makes the most sense.

[bob]

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

You can also put your foot under a running lawn mower, or put your hand into a bowl with a mixer running. But it is not a smart thing to do. If you use 10 threads on one CPU you hurt performance, and _badly_. So that should not even factor in to the discussion.

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.

Not correct. It has an underlying assumption (as do all parallel search programs) that each thread will run in _parallel_. This is not possible if you don't have a physical processor for each thread.

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

[bob]

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?

Cheers,
Andy

Come on guys. It is most _certainly "here or there". In chess, you use threads for parallel search. You might have another thread for input/output but it does not execute 100% of the time. This discussion has gone so far out into left field it is completely out of the stadium. For _any_ chess program that is currently in existence, you want _exactly_ one parallel search thread per physical CPU... Nothing else works.

[bob]

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.

Miguel

Sorry, but that is simply wrong. For parallel _computing_ we talk about threads and CPUs as being equal. Anything else makes absolutely no sense. You want to pick a term that a user can understand. If you boot linux with 4 single-core chips, two dual-core chips, or one quad-core chip, Linux or windows reports "4 cpus". And that is the term you want to use to set the number of search threads you expect to execute in parallel...

There are other reasons to use threads, from making the program design simpler (a threaded server for example), to making the algorithm faster. But for chess, it is _only_ about being faster. And N threads on M cpus, where N > M is going to kill performance, not help. You don't want to leave that confusion laying around...

[michiguel]

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.

Miguel

Sorry, but that is simply wrong. For parallel _computing_ we talk about threads and CPUs as being equal. Anything else makes absolutely no sense.

not true (not always CPUs == threads) because you can run an engine with two threads on a 4-CPU machine. In fact, you do that when you match it against another engine that uses 2 threads.

You want to pick a term that a user can understand. If you boot linux with 4 single-core chips, two dual-core chips, or one quad-core chip, Linux or windows reports "4 cpus". And that is the term you want to use to set the number of search threads you expect to execute in parallel...

There are other reasons to use threads, from making the program design simpler (a threaded server for example), to making the algorithm faster. But for chess, it is _only_ about being faster. And N threads on M cpus, where N > M is going to kill performance, not help. You don't want to leave that confusion laying around...

I insist, this is all geeky jargon that real chess players are not supposed to care about.

Miguel
PS: Nerds should not follow geeky nomenclature

[trojanfoe]

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?

Cheers,
Andy

Come on guys. It is most _certainly "here or there". In chess, you use threads for parallel search. You might have another thread for input/output but it does not execute 100% of the time. This discussion has gone so far out into left field it is completely out of the stadium. For _any_ chess program that is currently in existence, you want _exactly_ one parallel search thread per physical CPU... Nothing else works.

What even when that physical CPU has 2 or more cores? My opinion is that the setting should direct the operation of the engine; if it creates threads for its multi-CPU operation then it makes sense to call the parameter 'Threads'. If it spawns/forks processes then call it 'SpawnCPU' or whatever. I don't understand why so much fuss.

Cheers,
Andy

[bob]

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.

Miguel

Sorry, but that is simply wrong. For parallel _computing_ we talk about threads and CPUs as being equal. Anything else makes absolutely no sense.

not true (not always CPUs == threads) because you can run an engine with two threads on a 4-CPU machine. In fact, you do that when you match it against another engine that uses 2 threads.

OK, if you don't want optimal performance, you can run with threads < CPUS. But, by any definition I can find, that program is going to use CPUS = threads processors. On a quad-core, if you want to use two threads, it makes far more sense to say "I want to use two processors rather than the full four." We are _still_ talking about cpus or processors, not threads. But you will _never_ with any chess program run more processes than you have processors. And I do mean _never_.

You want to pick a term that a user can understand. If you boot linux with 4 single-core chips, two dual-core chips, or one quad-core chip, Linux or windows reports "4 cpus". And that is the term you want to use to set the number of search threads you expect to execute in parallel...

There are other reasons to use threads, from making the program design simpler (a threaded server for example), to making the algorithm faster. But for chess, it is _only_ about being faster. And N threads on M cpus, where N > M is going to kill performance, not help. You don't want to leave that confusion laying around...

I insist, this is all geeky jargon that real chess players are not supposed to care about.

Miguel
PS: Nerds should not follow geeky nomenclature

This is not "geeky jargon". It is the standard "jargon" (vocabulary is a far better term) used in any parallel programming reference. We use "processes" and "processors". Where sometimes "processes" < "processors" (you don't want to use entire machine to play chess, for example. And sometimes, "processes" > processors, when the program is not the classic compute-bound process and is doing I/O, web services, database accesses, network accesses, etc. But for chess, optimal is, and always has been, "processes" == "cpus". No exceptions. And I think that either "processors" or "cpus" is a perfectly acceptable term. "threads" is not. That _is_ a geeky term that only a few will really understand (probably < 10% of the readers here actually understand the difference, less than 1% _really_ understand the technical differences.