On-line engine blitz tourney November

[hgm]

Using external adapters to support different protocols might be easier to maintain, but it also has some drawbacks like needing two pipes instead of one for communication (which slows the communication down), and the extra translation step adds complexity which makes the chance that an error will occur larger IMHO.

Pipes are a pretty efficient way to communicate in most OS. I once timed it on an old Pentium M laptop, and it was about 1.5ms. That is negligible compared to the resolution of the system clock (~16ms) or the CECP time-measurement unit (10ms). On modern machines it might be faster. And protocol translation is a quite limited and well-defined task. Once it works, it works.

An additional advantage is that when you run the engine through a network, you can run adapter + engine on the remote machine, so that the efficient CECP can be used on the network. This might even speed up the communication.

Since Polyglot is an external adapter the only natural way to change settings is to edit it's ini file, adding the option to change UCI settings to a GUI that doesn't support UCI natively seems more like a hack to me.

I don't see any logic in that. How many threads or processes a program uses to do what it does is a technical implementation detail, and should not affect the user experience. You might as well say that "since Shredder is an external engine, the only natural way to change its settings is to edit an ini file". Obviously editing ini files is not very popular with users since the 80s; this is why engine-GUI communication protocols nowadays have commands for changing engine settings interactively, through a menu dialogs of the GUI.

What you propose would "leak" all kinds of technical details to the user. Which would actually have to know whether the engine is UCI or CECP, most likely never having heard of either, and having no clue what they mean. A good design would completely shield the user from such technical details, and provide the same optimal user experience no matter what type of engine they use.

[Joost Buijs]

What you propose would "leak" all kinds of technical details to the user. Which would actually have to know whether the engine is UCI or CECP, most likely never having heard of either, and having no clue what they mean. A good design would completely shield the user from such technical details, and provide the same optimal user experience no matter what type of engine they use.

I fully agree with the fact that a GUI should be user friendly and that it shouldn't bother the user with all kinds of technical details. However, this doesn't change my opinion that Polyglot (not being a part of Winboard, but an external adapter) is more or less hacked into Winboard, and that Winboard should not interfere with it's settings.

[hgm]

Polyglot is a protocol adapter, i.e. a program that makes an engine using one protocol appear as an engine using a diferent protocol. Whether an engine is able to accept setting changes through the protocol interface, and remember such setting changes from session to session, is a matter of engine design.

The version of Polyglot you are using happens to be designed to mimic a CECP engine that can be configured through the protocol interface, and can optionally (through Polyglot Save) remember its settings. This is what most users want, this is how UCI engines generally do it too. It is the engine design that gives the best user experience in WinBoard.

If you prefer a CECP engine that can only be configured through editing an ini file, you should just not use this Polyglot version, because it is not the kind of engine this version emulates. There are plenty of older Polylot versions that emulate legacy CECP engines that do not support the option feature that allows configuration through CECP commands.

BTW, UCI2WB is a protocol adapter that currently mimics a CECP engine that cannot remember its settings at all. It will always start with the default values for its options, and relies entirely on the GUI to configure it through the protocol interface every time it is started. So there is no equivalent to Polyglot Save there. To make this convenient, the latest WinBoard can remember non-default settings for engine options in its engine list, and will automatically add a Save button in the Engine Settings dialogs. This can then be used to save the current settings in the list of registered engines, so that future sessions with that same engine will keep using those settings. The advantage of this design is that settings can be remembered for CECP engines too, even when the engines cannot do this themselves. It was a bad idea to have the adapter perform such an essential function, as not every engine will run through an adapter.

[Ras]

However, this doesn't change my opinion that Polyglot (not being a part of Winboard, but an external adapter) is more or less hacked into Winboard

The whole Xboard protocol started as hack to put a GUI on top of Gnuchess.

With the adaptor, that's probably because it came from the Linux world: have many small tools each doing a single, well defined job. That's a bit alien under Windows where you have large monolithic applications. The underlying reason is that Windows has really bad process performance, and the work-around is to use threads and not processes as basic unit. This in turn leads to monolithic applications.

[Joost Buijs]

However, this doesn't change my opinion that Polyglot (not being a part of Winboard, but an external adapter) is more or less hacked into Winboard

The whole Xboard protocol started as hack to put a GUI on top of Gnuchess.

With the adaptor, that's probably because it came from the Linux world: have many small tools each doing a single, well defined job. That's a bit alien under Windows where you have large monolithic applications. The underlying reason is that Windows has really bad process performance, and the work-around is to use threads and not processes as basic unit. This in turn leads to monolithic applications.

Do you mean that Windows has bad inter process communication performance? This is my feeling too, under Windows pipes have a rather big latency, one of the reasons to avoid using them for serious applications. Using RPC or shared memory (by file mapping) usually performs better.

Since Winboard CECP seems to have internal timings of 10 ms. it probably doesn't matter at all. 10 ms. timing is not suitable for running games with very short (sub second) time controls whatsoever.

[Ras]

Do you mean that Windows has bad inter process communication performance?

I'm not sure about the actual IPC, but the process creation under Windows is pretty slow even without antivirus software running. Some benchmarking in https://www.bitsnbites.eu/benchmarking-os-primitives/ showed a Raspi 3 to be faster than a stock Win 10 with a Ryzen eight core CPU when launching programs.

That's what makes the Linux way of many small programs impractical. With thread creation, Windows is "only" three times slower than Linux.

10 ms. timing is not suitable for running games with very short (sub second) time controls whatsoever.

True. UCI wouldn't have this issue, but the Winboard side is CECP only. However, it doesn't make much sense to use a GUI for such fast games because the display will cost a disproportionate amount of time. It would make more sense to use a CLI solution.

[brianr]

True. UCI wouldn't have this issue, but the Winboard side is CECP only. However, it doesn't make much sense to use a GUI for such fast games because the display will cost a disproportionate amount of time. It would make more sense to use a CLI solution.

You may not know that Winboard has a no GUI option that minimizes display updates for fast games.

Why would UCI also not be susceptible to a Windows timer accuracy issue along with CECP?

[hgm]

I would be surprised if most engines would benefit from more accurate (i.e. msec) specification of the time on their clocks. The clocks they use for their own timing decisions typically also ticks only once every 16 msec. And scheduling delays would become very important at the msec level. You should not be surprised if execution pauses on the order of 10 msec will occur. If you really want to play such fast games, it is better to play them by node count. Otherwise there will be huge randomization due to OS intervention.

[brianr]

I would be surprised if most engines would benefit from more accurate (i.e. msec) specification of the time on their clocks. The clocks they use for their own timing decisions typically also ticks only once every 16 msec. And scheduling delays would become very important at the msec level. You should not be surprised if execution pauses on the order of 10 msec will occur. If you really want to play such fast games, it is better to play them by node count. Otherwise there will be huge randomization due to OS intervention.

Fully agree.

I was suggesting that just because the UCI go movetime command uses msec does not mean it is actually that accurate.

Even if you made the extra effort to use the higher precision timers, which might be useful for testing that engine against itself, there would be few if any other engines to play against that fast. And, since I doubt any tourney manager would be that accurate, the games would have to be run without time forfeits I think.

[Ras]

Why would UCI also not be susceptible to a Windows timer accuracy issue along with CECP?

Because UCI supports millisecond resolution on protocol layer and CECP doesn't. So, UCI engines have the possibility to be that precise. Also, I don't see why anyone would even use GetTickCount() with its low resolution - instead of QueryPerformanceCounter(), which is what my engine does under Windows.