Page 1 of 5

Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 5:04 pm
by hgm
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 8:03 pm
by Harald
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

Re: Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 8:21 pm
by hgm
Thanks for the feedback! I have tried to fix it.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 9:51 pm
by Dirt
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 10:32 pm
by hgm
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}

Re: Authors of WinBoard SMP engines, take note!

Posted: Sat Oct 11, 2008 10:40 pm
by plattyaj
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sun Oct 12, 2008 3:14 am
by bob
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sun Oct 12, 2008 9:46 am
by Ovyron
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sun Oct 12, 2008 12:48 pm
by Dirt
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.

Re: Authors of WinBoard SMP engines, take note!

Posted: Sun Oct 12, 2008 8:18 pm
by hgm
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.