Suggestions for running fast games with xboard

[cyberfish]

I made a few changes to xboard (HGM version) to make it more suitable for playing very fast games (a few seconds each side). After some testing... I found only 2 changes to have really helped.

1. in xboard.c, I made DisplayWhiteClock and DisplayBlackClock do nothing (return immediately). This makes xboard take almost no CPU. At 2s/40moves, drawing clocks (and updating the taskbar icon) takes about 80% of the other core on my Core 2 Duo at 3.3ghz. I suppose it's drawing the taskbar that matters, and will depend on window manager, etc. I am running Ubuntu 8.10, with compiz (desktop effects) and GNOME.

2.
backend.c

Code: Select all

void

TwoMachinesEventIfReady P((void))

{

  if (first.lastPing != first.lastPong) {

    DisplayMessage("", "Waiting for first chess program");

    ScheduleDelayedEvent(TwoMachinesEventIfReady, 1000);

    return;

  }

  if (second.lastPing != second.lastPong) {

    DisplayMessage("", "Waiting for second chess program");

    ScheduleDelayedEvent(TwoMachinesEventIfReady, 1000);

    return;

  }

  ThawUI();

  TwoMachinesEvent();

}

That introduces long (1 sec) delays between games (I am getting 4s/game on average... so that matters). Changing the timeouts to 100, for example, works for me. If I understand the code correctly, it should behave the same.

Any chance these 2 things can be made into a switch?

Also, while "Animate Moving" should obviously be disabled, "blind" surprisingly doesn't matter.

[hgm]

I can put suppression of the clock (and all other) display in an option -noDisplay

The other change I will make unconditionally. It just determines how many times per second XBoard checks if the engine is ready. Even if there was no delay at all, the code would work flawlessly. (But it would put a 100% load on the CPU, possibly delaying the engine it is waiting for.) Doing the check 100 times per second still should give a totally negligible load on a modern CPU, though. So I will lower the timeouts to 10 (msec).

[cyberfish]

Thanks, that would be great!

[ilari]

If you want to run fast games, maybe you should try Cutechess-cli, which doesn't even have a gui: http://www.talkchess.com/forum/viewtopic.php?t=27024

It never polls for anything or waits on a timer (not even between games), so there's no wasted time. And it's very efficient, using only a few hundred kilobytes of RAM and a very small percentage of CPU cycles.

[hgm]

The waiting is not for fun, you know. If you don't wait for the engine to start, or (when you are reusing it) to finish the move from the previous game it was thinking on, you might corrupt the results. Especially when temperamental engines are involved, that sometimes think very long on a single move. It means the engine would not forfeit a single game, but several games in a row, when it happens to get semi-stuck, distorting the match result.

[ilari]

The waiting is not for fun, you know. If you don't wait for the engine to start, or (when you are reusing it) to finish the move from the previous game it was thinking on, you might corrupt the results. Especially when temperamental engines are involved, that sometimes think very long on a single move. It means the engine would not forfeit a single game, but several games in a row, when it happens to get semi-stuck, distorting the match result.

Yeah I know, I've struggled with that when developing Cute Chess. So we're definitely making sure that the engine has finished playing. But we're not using timed waits or polling for that. With Xboard protocol 2 engines we can just use ping, but with others we wait for a move, a result, an error or something. It's a bit hackish, but I still feel that it works better than waiting for a constant time. Especially when you're running 1 second games you don't want any delay between the games.

[hgm]

OK, so you do wait for the engine to finish... For 1-sec games I could live with a delay of 10 msec between games, which is what the above (patched) code would give you. It could also be handled by setting a flag that a TwoMachinesEvent is requested, and let the code that processes the pong automatically cause a TwoMachinesEvent when it processes the required pong and this flag is set. This would create all kind of race conditions, though, so I seriously woner if it would be worth it to ave a few msec now and then. (Note that normally, for games that end in mate or engines that resign correctly, lastPing == lastPong, and no waiting would have to take place at all.)

I have my doubt about the fairness of time distribution between the engines anyway, in (sub-)1-sec games. Scheduling delays could easily be larger than the few msec we are talking about here.

[ilari]

OK, so you do wait for the engine to finish...

Yes, but not on a timer, like I said. We wait exactly as long as needed, but no longer than that.

But I don't think it would help if Xboard's delay between games was smaller. It would still take over 10 seconds to run a 1 second game, and flags would fall left and right. To run such fast games the whole GUI should be removed.

[cyberfish]

But I don't think it would help if Xboard's delay between games was smaller. It would still take over 10 seconds to run a 1 second game, and flags would fall left and right. To run such fast games the whole GUI should be removed.

I am getting an average of about 5 seconds per game (including initialization, etc) at 2s/40moves, which is quite reasonable (many games go above 40 moves).

The GUI doesn't take significant amount of CPU after removing the clocks and disabling moving animation.

[hgm]

It would still take over 10 seconds to run a 1 second game, and flags would fall left and right. To run such fast games the whole GUI should be removed.

Where the heck did you get that idea? When I run a match of ten 1+0 games of micro-Max 1.6 against itself under winboard /noGUI, the total match lasts 16 sec. That is only 1.6 sec per game. That is quite a bit shorter than the 10 sec you claim. Most games last more than 40 moves, and there are no losses on time. A 1+0 game could last upto 2 sec, so 1.6 sec is quite normal.

Sure, with other engines (in particular Fairy-Max) I have a lot of time losses, but that is a problem of the engine, that has too primitive a time control, and cannot handle a deep hash hit in the root. (uMax 1.6 has no hash table, and thus never exceeds the target time for its move by a large factor.) But this is not a GUI problem.