WinBoard protocol: memory command

Discussions about the WinBoard protocol. Here you can also report bugs and request new features.

Moderators: hgm, Andres Valverde

Re: WinBoard protocol: memory command

Postby H.G.Muller » 26 Sep 2008, 18:37

Perhaps I should put the info about the number of tablebases in the same command as the tablebase path, because logically they belong together (describing the part of the file system where the tablebases are). Like

egtpath nalimov F:\endgames\nalimov 3:5 4:40

As different future tablebase formats might have other informton that is relevant to them, I am in favor of rather loose definition of this command within WB protocol, like

egtbpath FORMAT PATHNAME [OTHERINFO]

where the syntax of the optional OTHERINFO is not really part of WB protocol, but can be defined by the inventor of the tablebase format. For nalimov we could define it as a space-separated list of MEN:NRFILES pairs. WinBoard would simply pass on the string the user had specified for the pathname, onto which the OTHERINFO is piggybacked, and never needs to know which part of it is pathname, which part of it is OTHERINFO, or what it means. E.g. through a comamnd-line option

/egtFormats="nalimov F:\endgames\nalimov 3:5 4:40,scorpio F:\endgames\bitbases 45"

WinBoard would parse the string argument as comma-separated list, and take the part before the first space in each item of the list a format name, and remember everything after that space as the string to be sent for that format.

The format names would be matched against those in the comma-separated list the engine sends with the features:

feature egt="nalimov,scorpio"

For each match (in this example both for nalimov and scorpio) it would then reply by the corresponding egtpath command, where as first argument to the command it would echo the format name that matched, and as second argument the string the user specified for this. So in this case

egtpath nalimov F:\endgames\nalimov 3:5 4:40
egtpath scorpio F:\endgames\bitbases 45

Format names specified by the engine, but not matching anything specified by the user, would not lead to any response. The asumption of the engine should be that the EGTs are not available unless it gets an explicit egtbpath command for them. Similarly, formats specified by the user, but not amongst the engine features, will also not lead to any commands; the assumption will be that the engine does not support them.
User avatar
H.G.Muller
 
Posts: 3207
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: WinBoard protocol: memory command

Postby F. Bluemers » 27 Sep 2008, 13:15

H.G.Muller wrote:Perhaps I should put the info about the number of tablebases in the same command as the tablebase path, because logically they belong together (describing the part of the file system where the tablebases are). Like

egtpath nalimov F:\endgames\nalimov 3:5 4:40

As different future tablebase formats might have other informton that is relevant to them, I am in favor of rather loose definition of this command within WB protocol, like

egtbpath FORMAT PATHNAME [OTHERINFO]

where the syntax of the optional OTHERINFO is not really part of WB protocol, but can be defined by the inventor of the tablebase format. For nalimov we could define it as a space-separated list of MEN:NRFILES pairs. WinBoard would simply pass on the string the user had specified for the pathname, onto which the OTHERINFO is piggybacked, and never needs to know which part of it is pathname, which part of it is OTHERINFO, or what it means. E.g. through a comamnd-line option

/egtFormats="nalimov F:\endgames\nalimov 3:5 4:40,scorpio F:\endgames\bitbases 45"

WinBoard would parse the string argument as comma-separated list, and take the part before the first space in each item of the list a format name, and remember everything after that space as the string to be sent for that format.

The format names would be matched against those in the comma-separated list the engine sends with the features:

feature egt="nalimov,scorpio"

For each match (in this example both for nalimov and scorpio) it would then reply by the corresponding egtpath command, where as first argument to the command it would echo the format name that matched, and as second argument the string the user specified for this. So in this case

egtpath nalimov F:\endgames\nalimov 3:5 4:40
egtpath scorpio F:\endgames\bitbases 45

Format names specified by the engine, but not matching anything specified by the user, would not lead to any response. The asumption of the engine should be that the EGTs are not available unless it gets an explicit egtbpath command for them. Similarly, formats specified by the user, but not amongst the engine features, will also not lead to any commands; the assumption will be that the engine does not support them.

while the memory command is one step forward ,this looks like two steps back :wink:
imo if an engine wants to use egtb's it should be smart enough to handle them itself and should do its own counting,if it wants to.
Just setting a path should do.


Best
Fonzy
F. Bluemers
 
Posts: 175
Joined: 04 Sep 2008, 16:56
Location: Netherlands

Re: WinBoard protocol: memory command

Postby Zach Wegner » 27 Sep 2008, 16:40

I have to agree with Fonzy here. The whole idea of sending the number of tablebases available is so that engines can allocate a reasonable amount of cache. This is IMO a microoptimization that will make very little difference, and most engine authors probably won't make use of it. For those that care enough about the difference (at most a few Elo), I don't think it would be so hard to write a 10 line function to count the TBs.
User avatar
Zach Wegner
 
Posts: 182
Joined: 26 Sep 2004, 22:02
Location: Austin, Texas, USA

Re: WinBoard protocol: memory command

Postby H.G.Muller » 27 Sep 2008, 18:15

Zach Wegner wrote:... For those that care enough about the difference (at most a few Elo), I don't think it would be so hard to write a 10 line function to count the TBs.

In fact only one open-source engine would have to write that code, as they can all clone it from each other, right?
User avatar
H.G.Muller
 
Posts: 3207
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: WinBoard protocol: memory command

Postby Zach Wegner » 27 Sep 2008, 20:55

Indeed. Keep the protocol simple I say.
User avatar
Zach Wegner
 
Posts: 182
Joined: 26 Sep 2004, 22:02
Location: Austin, Texas, USA

Re: WinBoard protocol: memory command

Postby Matthias Gemuh » 27 Sep 2008, 21:51

F. Bluemers wrote:
if an engine wants to use egtb's it should be smart enough to handle them itself and should do its own counting




Amen.
http://www.chessgui.com
http://w2410tmq9.homepage.t-online.de
BigLion, Taktix, ArcBishop, FindDraw, ChessGUI
User avatar
Matthias Gemuh
 
Posts: 189
Joined: 10 Jun 2006, 15:08

Re: WinBoard protocol: memory command

Postby H.G.Muller » 28 Sep 2008, 11:44

OK, it seems Ron is clearly outvoted.

For me it is difficut to judge which information would be important for an engine to know (and needlesly cumberome to figure out) in connection with tablebases, as none of my engines has ever used them. Basically I don't want WinBoard to be involved in the specific needs for various formats at all. Those defining the tablebase format should define the protocol with which they should be announced to the engines.

As I pointed out above, the way I will implement the commands can be abused esily to piggyback any information you want onto the path name, separated from it by spaces. Future formats, which must convey really essential information to the engine, can make use of that. Without any need to adapt the WB protocol, by leaving the format of the second and optional later parameters of the egtbpath command explicitly undefined.
User avatar
H.G.Muller
 
Posts: 3207
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: WinBoard protocol: memory command

Postby Daniel Shawul » 31 Oct 2008, 07:05

I am trying to implement these new commands but I have some doubts.

a)Does the final format for the "egtb" command has only the path? That is without
the egtb cache,membory for block indexes, and other internal egtb stuff.
The "memory N" command makes sure that every engine shoud come to the <= N bytes when
loaded. Is that correct?

b)cores N -> Mine can already handle this with another command "mt". But It does so
only outside of search. You mentioned that it should be able to handle it while pondering.
Scorpio stops pondering if it gets any message other than stat commands like "." during pondering.
Is that correct?

Questions from the old protocol:

c) I do not understand the "ping-pong" stuff in Winboard. It is suggested all engines should
implement it?

d) If the engine sends "done 0" at the beginning ,i.e when the pipe is just opened and before "xboard",
"protover" commands are sent, will xboard be able to process it? I need to do this to process
all initialization that might take some time at the beginning.

Daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: WinBoard protocol: memory command

Postby Tony Thomas » 31 Oct 2008, 07:46

I have a question for you H.G. Where do you keep the latest version of winboard? 4.3.15 for example.??
What more can I say?
Tony Thomas
 
Posts: 232
Joined: 14 May 2006, 19:13
Location: Atlanta, Ga

Re: WinBoard protocol: memory command

Postby H.G.Muller » 31 Oct 2008, 12:26

The latest version of the WinBoard executable is available at

http://home.hccnet.nl/h.g.muller/alpha.tst

Using it is at your own risk, though. I usually test if the features I add are working before I put it there, but not very thoroughly. And not at all if they have unintended side effects in other modes than they were intended for. (Which is always a big risk if you are changing programs that you don't really know.) So occasionally I might put a version there that is badly broken.
User avatar
H.G.Muller
 
Posts: 3207
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: WinBoard protocol: memory command

Postby Tony Thomas » 31 Oct 2008, 19:49

H.G.Muller wrote:The latest version of the WinBoard executable is available at

http://home.hccnet.nl/h.g.muller/alpha.tst

Using it is at your own risk, though. I usually test if the features I add are working before I put it there, but not very thoroughly. And not at all if they have unintended side effects in other modes than they were intended for. (Which is always a big risk if you are changing programs that you don't really know.) So occasionally I might put a version there that is badly broken.


Thanks... your history of fixing bugs isnt that bad...
What more can I say?
Tony Thomas
 
Posts: 232
Joined: 14 May 2006, 19:13
Location: Atlanta, Ga

Re: WinBoard protocol: memory command

Postby Roger Brown » 01 Nov 2008, 02:56

Tony Thomas wrote:I have a question for you H.G. Where do you keep the latest version of winboard? 4.3.15 for example.??




Hello Tony Thomas,

I am somewhat surprised at this post.

I thought you were an unrepentant Arena user?

What are you doing, fooling around with this ancient and backward gui?

:twisted:

Have fun.

Later.
Roger Brown
 
Posts: 346
Joined: 24 Sep 2004, 12:31

Re: WinBoard protocol: memory command

Postby Daniel Shawul » 02 Nov 2008, 03:34

Ok I would like to think this post of mine is not being ignored ,and got
buried somehow :)
For H.G : It would help you take your mind of the bitter posts in the other forum :)

Daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: WinBoard protocol: memory command

Postby Kerwin » 02 Nov 2008, 06:53

I prefer that the definition of the Memory command be a hard limit on the "total" memory usage of an engine. This includes code, static and dynamic tables for board maintenance, evaluation, etc. Defining it this way makes for a fair comparison of engines.

Think of it as the hardware limit itself. E.g., you have two identical machines, each with 1GB of memory, and it is up to the individual engines to make full use of the available memory.

Bitboard engines for example are notorious for large attack tables. Well, too bad for them - that just means that they would have less memory to allocate for transposition table.
Kerwin
 
Posts: 40
Joined: 30 Oct 2008, 07:29

Re: WinBoard protocol: memory command

Postby Tony Thomas » 04 Nov 2008, 21:40

Roger Brown wrote:
Tony Thomas wrote:I have a question for you H.G. Where do you keep the latest version of winboard? 4.3.15 for example.??




Hello Tony Thomas,

I am somewhat surprised at this post.

I thought you were an unrepentant Arena user?

What are you doing, fooling around with this ancient and backward gui?

:twisted:

Have fun.

Later.


I have to admit, I am a winboard newbie. I still dont know how to use it with a tournament manager..but so far it is the most reliable GUI I have ever used. I have not experienced any problems with winboard on icc. The only other GUI I have tried on ICC is chesspartner, and sometimes Romi lost communication with it and lost on time if I werent paying attention. Romi does manage time badly when ponder is turned on, but under winboard it never loses on time.
What more can I say?
Tony Thomas
 
Posts: 232
Joined: 14 May 2006, 19:13
Location: Atlanta, Ga

Next

Return to WinBoard development and bugfixing

Who is online

Users browsing this forum: Majestic-12 [Bot] and 1 guest

cron