UCI protocol and SMP

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
kranium
Posts: 1824
Joined: Thu May 29, 2008 8:43 am

Re: UCI protocol and SMP

Post by kranium » Fri Nov 14, 2008 12:43 pm

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?
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
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: UCI protocol and SMP

Post by mcostalba » Fri Nov 14, 2008 1:06 pm

bob wrote:
Zach Wegner wrote:
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

trojanfoe

Re: UCI protocol and SMP

Post by trojanfoe » Fri Nov 14, 2008 3:39 pm

mcostalba wrote:
bob wrote:
Zach Wegner wrote:
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?

Cheers,
Andy

User avatar
abik
Posts: 740
Joined: Fri Dec 01, 2006 9:46 pm
Location: Mountain View, CA, USA
Full name: Aart Bik
Contact:

Re: UCI protocol and SMP

Post by abik » Fri Nov 14, 2008 5:35 pm

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?

User avatar
Zach Wegner
Posts: 1922
Joined: Wed Mar 08, 2006 11:51 pm
Location: Earth
Contact:

Re: UCI protocol and SMP

Post by Zach Wegner » Fri Nov 14, 2008 5:53 pm

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

Michel
Posts: 2050
Joined: Sun Sep 28, 2008 11:50 pm

Re: UCI protocol and SMP

Post by Michel » Fri Nov 14, 2008 6:36 pm

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

User avatar
Zach Wegner
Posts: 1922
Joined: Wed Mar 08, 2006 11:51 pm
Location: Earth
Contact:

Re: UCI protocol and SMP

Post by Zach Wegner » Fri Nov 14, 2008 7:08 pm

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
Posts: 2050
Joined: Sun Sep 28, 2008 11:50 pm

Re: UCI protocol and SMP

Post by Michel » Fri Nov 14, 2008 7:27 pm

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

User avatar
michiguel
Posts: 6388
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: UCI protocol and SMP

Post by michiguel » Fri Nov 14, 2008 7:56 pm

mcostalba wrote:
bob wrote:
Zach Wegner wrote:
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. ;-)

Miguel

User avatar
Onno Garms
Posts: 224
Joined: Mon Mar 12, 2007 6:31 pm
Location: Bonn, Germany

Re: UCI protocol and SMP

Post by Onno Garms » Fri Nov 14, 2008 8:19 pm

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.

Post Reply