UCI protocol and SMP

[kranium]

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?

[mcostalba]

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

[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

[abik]

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?

[Zach Wegner]

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...

[Michel]

I think it should definitely be Threads.

I often run several threads on 1 CPU for testing. Of course performance goes down but for testing that's ok.

The default value for Threads should be the number of CPUs.


Regards,
Michel

[Zach Wegner]

Threads doesn't work, not all programs use threads (ZCT for one, it uses processes and shared memory).

Also, many end users won't know what threads are.

[Michel]

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)!

[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

[Onno Garms]

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.