Stockfish compiled by Visual Studio is much slower than by Cygwin?

[Joost Buijs]

According to Microsoft the slowness of the iostream library when printing to a console has to do with the way they designed it and it only seems to happen without io buffering. This is what they write about it:

It is an unfortunate consequence of how our C and C++ Standard Library implementations are designed. The problem is that when printing to the console (instead of, say, being redirected to a file), neither our C nor C++ I/O are buffered by default. This is sometimes concealed by the fact that C I/O functions like printf() and puts() temporarily enable buffering while doing their work.

It seems that: setvbuf(stdout, 0, _IOLBF, 4096); fixes the problem, obviously you don't want this for a chess engine. Maybe enable buffering when printing to the console and disable buffering when printing to an anonymous pipe would be a solution.

[Joost Buijs]

Enabling buffering and using a flush after each string could be another way to solve this, maybe Stockfish already flushes after each string, in that case just enabling buffering should fix it.

[phhnguyen]

It seems that: setvbuf(stdout, 0, _IOLBF, 4096); fixes the problem

You are right. Just tested: adding setvbuf to sf main and flush after all std::cout has solved the problem.

obviously you don't want this for a chess engine

Why not? is that a simple solution to make std::cout equal to printf function?

[Joost Buijs]

It seems that: setvbuf(stdout, 0, _IOLBF, 4096); fixes the problem

You are right. Just tested: adding setvbuf to sf main and flush after all std::cout has solved the problem.

obviously you don't want this for a chess engine

Why not? is that a simple solution to make std::cout equal to printf function?

In the past most engines used unbuffered IO to avoid hiccups in the communication between the engine and the GUI, I'm old school, and somehow I still try to avoid buffered IO, but flushing after each command works perfectly too, maybe my statement was a little bit premature.

[Sesse]

1) Why Stockfish exe compiled by VS differs from one by Cygwin/g++ when the source code is the same for both?

Because the compiler is allowed to output any binary that does what the source code says it should do. This is what allows compilers of today to produce ever-faster executables from the same source code. If not, we would still have had as bad compilers as we had in the 80s!

[Sesse]

It seems that: setvbuf(stdout, 0, _IOLBF, 4096); fixes the problem, obviously you don't want this for a chess engine. Maybe enable buffering when printing to the console and disable buffering when printing to an anonymous pipe would be a solution.

FWIW, this is the default in most UNIXes; console output is line buffered, pipe output is block buffered.

[syzygy]

That surprised me since I thought VS usually is better than gcc/g++ to create faster executive files for Windows.

As far as I know, this hasn't been true for a long time now.

Did I miss something? Anyway to improve Stockfish speed with VS? Thanks

Compiling with MingW probably gives still better speed with fewer (library) problems. In particular if you use "make profile-build".

[syzygy]

My first attempt was to replace them all by simple code std::cout (without io locks, BTW, I don't think Stockfish needs io lock here since it prints output from the main thread only) - the speed was the same (slow - half speed). However when I replaced them with C function printf (without io locks either), it gained back all losing speed.

This locking slowdown will disappear if you compile with MingW.

The lock is necessary because the main thread and the UI thread can try to print at the same time. For example, if the GUI sends "stop" and "isready" commands in quick succession, the response to isready may interfere with the response to stop (if locking is removed), and the GUI can get confused.

[syzygy]

Actually a weakness of the Stockfish bench, when you want to test search and evaluation performance the console output should be as minimal as possible.

Code: Select all

C:> stockfish bench >NUL

[Joost Buijs]

Actually a weakness of the Stockfish bench, when you want to test search and evaluation performance the console output should be as minimal as possible.

Code: Select all

C:> stockfish bench >NUL

Ahh I see, the final result is sent to cerr so this works.

With the Intel compiler v18 (Broadwell build, no PGO) I get:

Code: Select all

Total time (ms) : 2138
Nodes searched  : 4557946
Nodes/second    : 2131873

And with MSVC v14.1 (AVX2 build, no PGO) I get:

Code: Select all

Total time (ms) : 2184
Nodes searched  : 4557946
Nodes/second    : 2086971

Intel being ~2% faster, MSVC is not as bad anymore as it used to be.