Windows chess engines under Wine can be very slow

[mvanthoor]

Hi,

I've noticed this when running the Windows-version of Rustic in Wine, as I hoped to be able to use CuteChess for Windows in Wine to include Windows-only engines in my testing pool.

However, when Rustic runs in Wine, it achieves only 10% of its normal speed. Both the Linux version and the Windows version are fine, under Linux and Windows respectively. I've tried a version compiled on Windows, and a cross-compiled Linux -> Windows version, and both have the same problem.

The one thing I've been able to find is this:

https://wiki.winehq.org/Performance

applications that rely on precise thread scheduling will be disappointed (see e.g. http://hisouten.koumakan.jp/wiki/Linux_ ... olved_bugs )
applications that use kernel events heavily may run slowly (e.g. Unreal Tournament 3 - Stefan?)

Rustic has four threads:
- main engine thread
- search thread
- comm module input thread
- comm module output thread

If the engine receives an incoming uci / xboard command in the comm input thread, it'll send a message to the main engine thread so the engine can react to it. (Like, start or stop the search, quit, resize the TT, etc). If the engine needs to send a response, then this response is sent to the comm output thread.

Thus Rustic has heavy inter-thread communication through channels. I assume this is either "precise thread scheduling" or "heavy use of kernel events"; many of the other engines I've tried are completely single-threaded, with protocol I/O interwoven into the engine. (Peeking in the keyboard buffer for input, printing from any location in the engine, mainly.) These engines run fine.

Still, it makes Wine a no-go for a testing platform, because some engines may run very slowly, which is obviously is a massive disadvantage.

Or, someone maybe has a suggestion or a trick to improve this....

[amanjpro]

Wine-is really a no go, wine is only good for drinking

I compile my own binaries almost all the time, after all most C/C++ engines compile just fine under Linux, and all of them have their make files, and from experinece Linux builds are usually much faster than the Windows builds anyways, so it is a win win situation

[mar]

Or, someone maybe has a suggestion or a trick to improve this....

I use 2 threads (no idea why you'd need more than that) in my engine (input and search, unless SMP is on) and it achieves
~90% of the speed under Wine (compared to the native linux build), part of which might be the difference between linux and windows compiles
you must be doing something wrong

[mvanthoor]

[you must be doing something wrong

In this case, Wine has to be the problem. The engine runs full speed on Windows, and at exactly the same speed when compiled for Linux. It's only slow when running under Wine.

I could have merged the input and output thread, or even the input, output and engine threads, but I wanted everything to be separated and completely self-contained. The engine (or search) doesn't even know the communication is by UCI or XBoard; it would even be possible to receive UCI-commands and send XBoard replies, without the comm module itself knowing about it. In essence, the engine could even be changed into some sort of Polyglot-like adapter/referee with very little code change. You don't -need- separate threads for this, but it keeps everything independent.

Maybe the engine is a bit over-engineered in this regard, but in this way it can be adapted to whatever protocol or search setup I'd want.

[gflohr]

Has anybody tried running chess engines in containers?

Especially for Windows developers that should be an easy way to provide an executable for Linux/Mac because there is no need for a cross-compiling toolchain.

[j.t.]

...

I just tried running Rustic Alpha 3.0.0 BMI2 with wine and native on Linux:

Code: Select all

$ wine rustic-alpha-3.0.0-windows-64-bit-bmi2.exe

The wine version is running at ~95% of the speed the native version is running at. If your dev version runs at only 10% of the speed when directly used with wine, then it is likely that you can fix it in your code.

[mvanthoor]

I just tried running Rustic Alpha 3.0.0 BMI2 with wine and native on Linux:

Code: Select all

$ wine rustic-alpha-3.0.0-windows-64-bit-bmi2.exe

The wine version is running at ~95% of the speed the native version is running at. If your dev version runs at only 10% of the speed when directly used with wine, then it is likely that you can fix it in your code.

Thanks for trying. Very strange. I'm using the latest Wine (6.14) via Lutris. It could be that I built my executable in debug mode by accident (which I don't think), or the problem is the specific version of Wine. Rustic's design hasn't changed since version Alpha 1; 3.0.0 is exactly the same as my current dev version in that regard.

[Ras]

I checked my engine, and Wine with the Windows executable gets me 97.8% of the native Linux version. Same compiler, same compiler settings. I have an input and a search thread, and all output (may come from the input or the search thread) is guarded with a mutex. Also, the Windows version uses the native WinAPI, not the MingW pthread library.

[mvanthoor]

I checked my engine, and Wine with the Windows executable gets me 97.8% of the native Linux version. Same compiler, same compiler settings. I have an input and a search thread, and all output (may come from the input or the search thread) is guarded with a mutex. Also, the Windows version uses the native WinAPI, not the MingW pthread library.

Tested with different Wine versions...

Native linux version:

Code: Select all

go depth 10
info score cp 29 depth 1 seldepth 1 time 0 nodes 24 nps 0 pv d2d4
info score cp 0 depth 2 seldepth 2 time 0 nodes 90 nps 0 pv d2d4 d7d5
info score cp 27 depth 3 seldepth 5 time 0 nodes 672 nps 0 pv d2d4 d7d5 g1f3
info score cp 0 depth 4 seldepth 8 time 2 nodes 2292 nps 1146000 pv d2d4 d7d5 g1f3 g8f6
info score cp 27 depth 5 seldepth 12 time 5 nodes 13957 nps 2791400 pv d2d4 d7d5 g1f3 b8c6 b1c3
info score cp 0 depth 6 seldepth 18 time 14 nodes 66545 nps 4753214 hashfull 4 pv d2d4 d7d5 g1f3 g8f6 f3e5 f6e4
info score cp 19 depth 7 seldepth 18 time 43 nodes 300952 nps 6998884 hashfull 14 pv d2d4 d7d5 g1f3 g8f6 b1c3 b8c6 f3g5
info score cp 8 depth 8 seldepth 23 time 305 nodes 2059811 nps 6753479 hashfull 109 pv e2e4 e7e5 b1c3 b8c6 g1f3 g8f6 d2d4 e5d4 f3d4 c6d4 d1d4
info score cp 27 depth 9 seldepth 23 time 1368 nodes 9268090 nps 6774920 hashfull 411 pv e2e4 b8c6 g1f3 g8f6 f1d3 d7d5 e4d5 f6d5 e1g1
info score cp 6 depth 10 seldepth 24 time 6183 nodes 41775192 nps 6756460 hashfull 957 pv g1f3 g8f6 b1c3 b8c6 e2e4 e7e5 f1c4 f8d6 e1g1 e8g8
bestmove g1f3

Speed: 6.756.460 nps at depth 10.

Windows version, cross-compiled under Linux, using the windows-gnu toolchain I'd also use under Windows itself. I am assuming that windows-msvc won't run on Linux because it needs the MSVC linker, which on Windows, you'd need to install from the Visual C++ build tools.. (But I haven't tried this.)

Running on Debian 11 system Wine, version 5.03

Code: Select all

go depth 10
info score cp 29 depth 1 seldepth 1 time 0 nodes 24 nps 0 pv d2d4
info score cp 0 depth 2 seldepth 2 time 0 nodes 90 nps 0 pv d2d4 d7d5
info score cp 27 depth 3 seldepth 5 time 0 nodes 672 nps 0 pv d2d4 d7d5 g1f3
info score cp 0 depth 4 seldepth 8 time 2 nodes 2292 nps 1146000 pv d2d4 d7d5 g1f3 g8f6
info score cp 27 depth 5 seldepth 12 time 5 nodes 13957 nps 2791400 pv d2d4 d7d5 g1f3 b8c6 b1c3
info score cp 0 depth 6 seldepth 18 time 15 nodes 66545 nps 4436333 hashfull 4 pv d2d4 d7d5 g1f3 g8f6 f3e5 f6e4
info score cp 19 depth 7 seldepth 18 time 47 nodes 300952 nps 6403234 hashfull 14 pv d2d4 d7d5 g1f3 g8f6 b1c3 b8c6 f3g5
info score cp 8 depth 8 seldepth 23 time 334 nodes 2059811 nps 6167099 hashfull 109 pv e2e4 e7e5 b1c3 b8c6 g1f3 g8f6 d2d4 e5d4 f3d4 c6d4 d1d4
info score cp 27 depth 9 seldepth 23 time 1497 nodes 9268090 nps 6191109 hashfull 411 pv e2e4 b8c6 g1f3 g8f6 f1d3 d7d5 e4d5 f6d5 e1g1
info score cp 6 depth 10 seldepth 24 time 6769 nodes 41775192 nps 6171546 hashfull 957 pv g1f3 g8f6 b1c3 b8c6 e2e4 e7e5 f1c4 f8d6 e1g1 e8g8
bestmove g1f3

Speed: 6.171.546 at depth 10.
Result: 91.34%

So Wine causes an 8-9% speed penalty.

That is in league with what I'd expect.

Running under Wine 6.14 Staging (as installed by Lutris):

Code: Select all

go depth 10
info score cp 29 depth 1 seldepth 1 time 0 nodes 24 nps 0 pv d2d4
info score cp 0 depth 2 seldepth 2 time 0 nodes 90 nps 0 pv d2d4 d7d5
info score cp 27 depth 3 seldepth 5 time 2 nodes 672 nps 336000 pv d2d4 d7d5 g1f3
info score cp 0 depth 4 seldepth 8 time 6 nodes 2292 nps 382000 pv d2d4 d7d5 g1f3 g8f6
info score cp 27 depth 5 seldepth 12 time 14 nodes 13957 nps 996929 pv d2d4 d7d5 g1f3 b8c6 b1c3
info score cp 0 depth 6 seldepth 18 time 72 nodes 66545 nps 924236 hashfull 4 pv d2d4 d7d5 g1f3 g8f6 f3e5 f6e4
info score cp 19 depth 7 seldepth 18 time 248 nodes 300952 nps 1213516 hashfull 14 pv d2d4 d7d5 g1f3 g8f6 b1c3 b8c6 f3g5
info score cp 8 depth 8 seldepth 23 time 1894 nodes 2059811 nps 1087545 hashfull 109 pv e2e4 e7e5 b1c3 b8c6 g1f3 g8f6 d2
d4 e5d4 f3d4 c6d4 d1d4
info score cp 27 depth 9 seldepth 23 time 8159 nodes 9268090 nps 1135935 hashfull 411 pv e2e4 b8c6 g1f3 g8f6 f1d3 d7d5 e4d5 f6d5 e1g1

Speed: 1.135.935 nps
Result: 16.8%

(In some previous runs, I've also had speeds of around 700 kNodes/s, for a speed of only 8-10%)

I have Fritz 11 running under Wine/Lutris, using Wine 6.14 Staging as a runner. The node count in the Fritz 11 GUI is the same as it is on the Wine 6.14 command line: either 1.1 million nps, or 700 kNodes/s (I don't know why it is sometimes even slower.) Therefore I just switched the runner from Lutris' built-in 6.14 staging to system Wine; the same 5.03 version that gained 91+% of the speed of the native version.

The node count in the Fritz 11 GUI went up accordingly, and it is now also in the 6.1 million (91-92%) speed range.

So, the problem is clearly somewhere within Wine 6.14, or the specific build of Wine 6.14 that Lutris is using. The strange thing is that it does not affect all engines (some take a bigger hit than others, but none under 85%, except mine), and games are not affected as far as I can see. I'd know if a game would run at 15% of its normal speed.

So for now, I'll just use system Wine (or test other Lutris versions) for Fritz 11, until I find a Linux-specific GUI I like better. And, at 91-92% speed, tseting engines under Wine is an option, if there are no open source engines in the Elo-range I want to test.

[mvanthoor]

It's definitely a problem with some versions of Wine built by, or for, Lutris:

6.16-1: OK (fastest, 6.4 million nodes/s) (GE / Glorious Eggroll version)
6.14-4: Busted (~750 kNodes/s, sometimes 1.3 million nodes/s after a restart (?))
6.13-3: Busted (~500 kNodes/)
6.10-7: OK (6.1 - 6.2 million nps)
6.1-3: OK (6.1 - 6.2 million nps)
5.7-11: OK (6.1 - 6.2 million nps)
5.0.3: OK (6.1 - 6.2 million nps) (System Wine on Debian 11 Bullseye)

Running on version 6.16-1 GE, the engine reaches a speed up to 6.4 million nps, or roughly 95% of its native speed. It's the fastest version I've tested on up until now. On other Wine versions in Lutris such as 6.13-3, the engine is as slow as 500 kNodes/s.

When installing Wine runners in Lutris, I leave everything at the default except if I need to change it for a specific game. I also try the newest runners first when running games. I think I'm going to switch the games I'm playing over to 6.16-1 GE, assuming they don't break.