hgm wrote:As already pointed out, this is debug output from XBoard. It would not be generated when you don't run XBoard in -debug mode, so normally it couldnot cause any slowdown. The move parser prints the board every time it fails to disambiguate a SAN move. In this case that probably happens because it tries to parse the first move of Gaviota's PV, and it is a move for the wrong side (as Gaviota is pondering), and thus illegal. This might be Gaviota or XBoard's fault, for trying to parse the move in the wrong position, by not sending or not performing the ponder move.
XBoard tries to identify the first PV move for sorting PVs of the same depth by score (for good multi-PV output), but it should not re-order PVs that start with the same move, irrespective of score (as they are probably re-searches of non-indicated fail highs).
It is debatable if I should do all that for ponder output; suppressing the sorting during ponder would be a simple way to avoid the problem. I doubt that this would eat very much time when not in debug mode; the printing to the debug file could take some time.
Note that the debug file is primarily intended as a tool to debug XBoard.
It is true that engine input is handled in XBoard by generating events in the event loop of the widget set (Xaw or GTK), and that events cannot interrupt each other. An input event handles all input received in a single read operation, even if it is multi-line. So it is in theory possible for one engine to lock out the other, by flooding XBoard with difficult-to-process output.
I guess the simples way to avoid is, is to poll for input of the other engine in the low-level input event handler that splits up the engine input in lines. It could then recursively start to handle events for that other engine before handling the remaining lines from the pondering engine. This is a bit tricky, because a flooding engine might interrupt the processing even of its own input.
OK, answers that. The problem I was really trying to track down was late in the game, where the opponent was hitting 50+ plies, dumping a PV and such for each iteration. IE 100-200 (or more) lines of output almost instantly, which causes a significant load on xboard, noticeable because the clocks stop getting updated and disappear. Works pretty well if I don't allow pondering so the other program is not sending output while Crafty is thinking or trying to make a move...
Here's an oddity. I have been working on various things, and have been seeing some unexpected losses running with board. I decided to try a new opponent, and downloaded gaviota. It behaves VERY poorly. It dumps an absolute ton of garbage while it is playing. It displays multiple 8x8 boards of numbers, plus a couple of hundred array values, etc, after each move.
Gaviota does not do any of that. Sven explains it in another post (it seems you are looking at the wrong lines). If you want to limit Gaviota output even more, check the ini file (or the options in the xboard gui), you have there a couple of parameters to control the noise.
Miguel
I looked in the as-distributed .ini file (this is an os x pre-compiled version). I didn't see anything that addresses this... Is it possible for Giovatta to send something to board that puts it in some oddball mode? I don't see ANY of those 8x8 dumps when I play Crafty vs Crafty. Nor with Crafty vs Scorpio (or stockfish, arisen 17.x, etc...)
In the ini file you find
;-----------------------------------------------------------------------------
; VERBOSITY (Output)
; mute_plies = won't display any information until this iteration is reached
; terse_plies = it will show only completed iterations, no PV updates
; root_upates = on/off, if 'on' it will show what current move is being
; analyzed (useful only in UCI mode)
;-----------------------------------------------------------------------------
mute_plies = 8
terse_plies = 14
root_updates = off
Bad program makes a move, and then starts sending lots of garbage, which continually unblocks xboard for it to read that input. Meanwhile good program finally gets the move, thinks, and sends its move back, but xboard is backlogged processing all the bad program output, so if it is not careful, it will spend all of its time reading that input first, and only reading the good move later, and that program gets charged for all of that time.
Perhaps one suggestion is for xboard to time penalize all non-CECP output from an engine, and add the time in favor to the compliant engine. This should motivate operators to minimize output.
The 8x8-output time should go in favor to the compliant engine if it generated by xboard, or at least interpreted by xboard as "silent" time not affecting either engine. On the other hand, perhaps running debug in the background should void any expected conditions from the user. Xboard cannot be both user friendly on extraneous debug output, and restrictive on CECP time expectations at the same time.
But sending Thinking Output is compliant, and the CECP specs don't put any limit on how many PVs you can send per second, or what the maximum length of the PV can be. So a malicious engine can send 10,000 PVs each 1000 moves long each second.
Of course practices like this count as 'electronic warfare', and there are plenty of methods to wage such a war on an opponent running on the same computer that do not involve the GUI. E.g. you can flush the shared cache levels at maximum rate to hinder the opponent.
hgm wrote:But sending Thinking Output is compliant, and the CECP specs don't put any limit on how many PVs you can send per second, or what the maximum length of the PV can be. So a malicious engine can send 10,000 PVs each 1000 moves long each second.
Of course practices like this count as 'electronic warfare', and there are plenty of methods to wage such a war on an opponent running on the same computer that do not involve the GUI. E.g. you can flush the shared cache levels at maximum rate to hinder the opponent.
It certainly is malice to tax 100,000 PV moves per second on a chess game. However, this sort of thing is no longer an electronic logical judgement for an interface, but a moral decision to be made by the limitations of human tolerance.
Here's an oddity. I have been working on various things, and have been seeing some unexpected losses running with board. I decided to try a new opponent, and downloaded gaviota. It behaves VERY poorly. It dumps an absolute ton of garbage while it is playing. It displays multiple 8x8 boards of numbers, plus a couple of hundred array values, etc, after each move.
Gaviota does not do any of that. Sven explains it in another post (it seems you are looking at the wrong lines). If you want to limit Gaviota output even more, check the ini file (or the options in the xboard gui), you have there a couple of parameters to control the noise.
Miguel
I looked in the as-distributed .ini file (this is an os x pre-compiled version). I didn't see anything that addresses this... Is it possible for Giovatta to send something to board that puts it in some oddball mode? I don't see ANY of those 8x8 dumps when I play Crafty vs Crafty. Nor with Crafty vs Scorpio (or stockfish, arisen 17.x, etc...)
In the ini file you find
;-----------------------------------------------------------------------------
; VERBOSITY (Output)
; mute_plies = won't display any information until this iteration is reached
; terse_plies = it will show only completed iterations, no PV updates
; root_upates = on/off, if 'on' it will show what current move is being
; analyzed (useful only in UCI mode)
;-----------------------------------------------------------------------------
mute_plies = 8
terse_plies = 14
root_updates = off
Miguel
That's not in the mac os x version I downloaded. I'll certainly add it. I assume "mute_plies means no output for first 8 iterations? That's not going to help for endgames where 30-40-50 plies are sometimes trivial.
In Crafty, I do something that works better for me, namely say "no output for N seconds" unless the search terminates, then always show the last PV no matter how short a time it took to search, so it will always give one PV for the engine output window no matter what setting for noise is used... noise 99999 is the least chatty, but for long games, you only get a PV when it makes a move. I generally use about 1/3 of the basic time per move to cut out the early noise...
