Authors of WinBoard SMP engines, take note!

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
hgm
Posts: 23713
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Authors of WinBoard SMP engines, take note!

Post by hgm » Sat Oct 11, 2008 3:04 pm

WinBoard protocol will be extended with a new command to facilitate controlling of SMP engines:

cores N

will be sent by future WinBoard versions at the start of every game (just after the ponder-control commands "hard" and "easy", and the new "memory" command). N specifies the number of CPU cores (search threads) the engine is allowed to use, maximally. The engine should be prepared to handle the "cores" command also during te game, just as the ponder state can be changed during the game. Deferring the effect of a "cores" command until after completion of the current search is allowed, though.

The usage of the "cores" command has to be explicitly enabed by the engine, by sending "feature smp=1" to xboard amongst the other features at startup. Authors of SMP engines are encouaged to implement this feature, and make their engine receptive to the "cores" command, so that it becomes easier for users to control the number of cores used by the engine, even during a game.

For a detailed description of the "cores" command and other commands, see the extended WinBoard protocol document.

Harald
Posts: 265
Joined: Thu Mar 09, 2006 12:07 am

Re: Authors of WinBoard SMP engines, take note!

Post by Harald » Sat Oct 11, 2008 6:03 pm

hgm wrote:WinBoard protocol will be extended with a new command to facilitate controlling of SMP engines:
...
For a detailed description of the "cores" command and other commands, see the extended WinBoard protocol document.
In the Chess Engine Communication Protocol I just read the green and blue lines.
With this post I want to help you make a good work a little bit more perfect.

- otim N ... Not that the way the clocks operate and receive extra time ...
-> otim N ... Note that the way the clocks operate and receive extra time ...

- edit ... upto ...
-> edit ... up to ...

- core N ... for SMP engines(Threads ...
-> core N ... for SMP engines (Threads ...

- cores N ... The engine can use this to set the size of its hash tables.
-> Sorry, I do not understand that.

Harald

User avatar
hgm
Posts: 23713
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Authors of WinBoard SMP engines, take note!

Post by hgm » Sat Oct 11, 2008 6:21 pm

Thanks for the feedback! I have tried to fix it.

Dirt
Posts: 2851
Joined: Wed Mar 08, 2006 9:01 pm
Location: Irvine, CA, USA

Re: Authors of WinBoard SMP engines, take note!

Post by Dirt » Sat Oct 11, 2008 7:51 pm

Any plans to implement a multi-PV mode in Winboard? With a change to Polyglot there could suddenly be a large number of engines that would use it.

User avatar
hgm
Posts: 23713
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Authors of WinBoard SMP engines, take note!

Post by hgm » Sat Oct 11, 2008 8:32 pm

I had no plans in that direction, as I don't even know what multi-PV mode is. But I am always open to suggestions. If you can explain me what it is supposed to do...

For those that already want to try the new command: the alpha.tst now on my website supports the "cores", "memory" and "egtpath" commands. To control the values that are sent, I added two command-line options

/smpCores=N

and

/egtFormats={nalimov:c:\egtb,scorpio:c\bitbases}

plattyaj

Re: Authors of WinBoard SMP engines, take note!

Post by plattyaj » Sat Oct 11, 2008 8:40 pm

hgm wrote:I had no plans in that direction, as I don't even know what multi-PV mode is. But I am always open to suggestions. If you can explain me what it is supposed to do...
Multi-PV tells an engine to consider not just the "best" move but the next best and so on. UCI has it - and the ability to restrict the set of moves to consider. Having used it a few times with Shredder I'm not convinced of it's usefulness.

Andy.

bob
Posts: 20549
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Authors of WinBoard SMP engines, take note!

Post by bob » Sun Oct 12, 2008 1:14 am

hgm wrote:WinBoard protocol will be extended with a new command to facilitate controlling of SMP engines:

cores N

will be sent by future WinBoard versions at the start of every game (just after the ponder-control commands "hard" and "easy", and the new "memory" command). N specifies the number of CPU cores (search threads) the engine is allowed to use, maximally. The engine should be prepared to handle the "cores" command also during te game, just as the ponder state can be changed during the game. Deferring the effect of a "cores" command until after completion of the current search is allowed, though.

The usage of the "cores" command has to be explicitly enabed by the engine, by sending "feature smp=1" to xboard amongst the other features at startup. Authors of SMP engines are encouaged to implement this feature, and make their engine receptive to the "cores" command, so that it becomes easier for users to control the number of cores used by the engine, even during a game.

For a detailed description of the "cores" command and other commands, see the extended WinBoard protocol document.
My only thought is that I don't like the term "cores". Better would be "processors" or "cpus" or "threads" or "processes" or something. "core" is an intel term and is related to a single CPU chip and how many physical processors are in it.

User avatar
Ovyron
Posts: 2701
Joined: Tue Jul 03, 2007 2:30 am

Re: Authors of WinBoard SMP engines, take note!

Post by Ovyron » Sun Oct 12, 2008 7:46 am

plattyaj wrote:Having used it a few times with Shredder I'm not convinced of it's usefulness.
Multi-PV isn't very useful when you have exclude moves, but UCI engines like Zappa Mexico don't have exclude moves so Multi-PV is really important for analyzing when you want to know what's the second best move of a position.

Dirt
Posts: 2851
Joined: Wed Mar 08, 2006 9:01 pm
Location: Irvine, CA, USA

Re: Authors of WinBoard SMP engines, take note!

Post by Dirt » Sun Oct 12, 2008 10:48 am

hgm wrote:I had no plans in that direction, as I don't even know what multi-PV mode is. But I am always open to suggestions. If you can explain me what it is supposed to do...
Instead of the engine just returning the best line from a position, it shows the best n lines.

For instance, here is a screen shot of Anmon in Arena doing an analysis in three variation mode.

Many UCI engines support this, and I think it's useful. I prefer Winboard enough that I actually haven't used it much, though.

User avatar
hgm
Posts: 23713
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Authors of WinBoard SMP engines, take note!

Post by hgm » Sun Oct 12, 2008 6:18 pm

It looks like something that could easily fit in the engine-output window. That Window displays every line of thinking output anyway. So the only thing that would be needed is that the engine would send N lines of thinking output (with its N best lines) for every iteration. Then WinBoard would not even have to know the engine is in multi-PV mode. So in a sense WinBoard already supports multi-PV mode, if the engine does.

Of course it would be handy if you could interactively switch multi-PV mode on and off, through WB protocol. It would be easy enough to add a command "multipv N" to WB protocol, the sending of which would be enabled by the engine through "feature multi=1". The value of N could be set by a command-line option "/multiPV=N". All that would be trivial to add. Adding a menu to change N interactively would be a bit more work. In fact I'd rather not add any new menus before we unified the menu code for xboard and WinBoard, as this probably means that all menu code of either goes to the garbage bin. So any time spent on it now would be wasted time.

Post Reply