Hash table allocaton time & GUI clock

[hgm]

There seems to be a problem in WB protocol:

Before every game it sends a memory command, just in case the user changed the hash-table settings; such a change is not relayed during a game. Normally this means the engine just gets reconfirmation for the hash size it already uses, and ignores the command.

But on the first game it usually has to really allocate the memory, and this can take a significant amount of time, like 6-20 sec, depending on how much you ask, and much memory your computer has,and how heavily it is loaded. Currently the clocks already run during this period.

The question is now if this is reasonable and / or desirable.

Actually I do think it is reasonable that grabbing or initializing resources is just as much part of anything the engine does to decide abouts its move as search or pondering. But the required time is only needed during a first game, leading to effectively different standards between games, and the second engine usually suffers much more than the first (because the latter grabs the easily available memory), which leads to asymmetry between opponents, and both of that is very undesirable.

So I guess it would be better to not start the clocks before the engine has processed a change in its hash size. That means I should make WinBoard really wait for the pong in response to the ping it sends after new for both engines, before starting the clock and sending the go commands. Currently WinBoard does not wait for pongs, but just uses them as 'fences' to decide which engine output belongs to the current game, and which to a previous one (and thus can be ignored).

[Michel]

That means I should make WinBoard really wait for the pong in response to the ping it sends after new for both engines, before starting the clock and sending the go commands.

This is the purpose of isready/readyok in the UCI protocol. These commands are not needed to prevent race conditions (I think there aren't any) but to make sure
that initialization time is not budgetted on the engine.

[rbarreira]

In what circumstances did you see such a long allocation time? I've never seen anything like it.

[hgm]

http://www.open-aurec.com/wbforum/viewt ... =2&t=51689

[hgm]

This is the purpose of isready/readyok in the UCI protocol. These commands are not needed to prevent race conditions (I think there aren't any) but to make sure
that initialization time is not budgetted on the engine.

Indeed, and ping / pong is the WB equivalent to it. So I suppose that if WB sends ping N to Polyglot, Polygot would relay it to the UCI engine as isready, and then relay the engine's readyok to WB as pong N, before it continues processing any input from the GUI again. (There could be a ping N+1 amongst those pending commands!)

[Onno Garms]

This is the purpose of isready/readyok in the UCI protocol. These commands are not needed to prevent race conditions (I think there aren't any) but to make sure
that initialization time is not budgetted on the engine.

I think that's true, but the Shredder GUI is quite impatient with the initialization. It reported engine loading problems with Onno once in 500 games or so. I then moved part of the initalization to the first go command which fixed the problem.

I normally play 1 min + 1s, so even if there are a few seconds of initialization (normally there are not), it doesn't hurt me much. Might look different if you play 0min + 1s.