gcc4.8 outperforming gcc5, gcc6, gcc7

[Dann Corbit]

What OS?

Windows 10, Windows 2012 Server

What CPU?

Intel and AMD

What Flags?

O3, pgo and the typical flag set. Something I always add that I rarely see others use is:

Code: Select all

	ifeq ($(comp),mingw)
		CXXFLAGS += -mtune=native
        endif

and I always link statically in case someone wants a copy of the binary.

[AndrewGrant]

Final question. GCC or G++?

I tried doing a PGO build, and actually got a different bench... which really confuses me.

[Dann Corbit]

Final question. GCC or G++?

Both.

I tried doing a PGO build, and actually got a different bench... which really confuses me.

I guess that you have undefined behavior in your code.
My recommendation is to use both GCC and CLANG with warnings turned up to crazy maximum and examine each and every one. (Expect thousands).

Now, I assume by bench you mean something that should be reproducible like perft or perhaps a single threaded search. I would not expect a multi-threaded search to give the same result even on the same machine and binary when repeated. It is possible for a somewhat different single threaded bench on a search to be correct. What I mean is that the code is slightly different with things like inlining instead of function calls. Most of the time these changes make no difference. If you have floating point anywhere in your program, that can do all kinds of whacky things. For instance, the total of a long column of floating point numbers which vary greatly in size will be different if you sum them forward or backwards and different again if you sort them first. Even using Kahan's adder won't completely fix that sort of thing. It only reduces the effect.


What exactly does your bench do?

[AndrewGrant]

I already do gcc -Wall -Wextra -Wshadow, but I'll look for more flags. I currently get no warnings when I compile.

I have a bench the same way stockfish does. Do a depth 13 search on a set of positions. Single threaded. I have no problem reproducing the bench on any non PGO compile, accross the 7+ machines I've run it on

I'll see what I can do tonight, when I get back to my computer with clang

[Ras]

My recommendation is to use both GCC and CLANG with warnings turned up to crazy maximum and examine each and every one. (Expect thousands).

A quick check with CppCheck didn't show much besides scoping, but I'm not sure whether reduced scopes actually help speed. Maybe.

GCC under Linux offers tons of "sanitizer" options with checks during runtime. Slow of course, but good for spotting errors.

Coverity Scan is a nice option because it's free for Open Source projects; I'm also using it.

And btw., the makefile already has "-Wall -Wextra -Wshadow", so the warnings are already cranked up.

However, there is one thing where I'm not too sure. There is no clear compiler directive how to deal with pointer aliasing, and GCC changed that with 4.9 towards (ab)using it for optimisation. It's totally easy to get this in, and unless benchmarking shows a clear gain, I'd always use "-fno-strict-aliasing" for release, and while we're at it, also "-fno-strict-overflow".

[abulmo2]

Final question. GCC or G++?

I tried doing a PGO build, and actually got a different bench... which really confuses me.

I try to play with your code and get the same observation. As the gcc with -Ofast flag and the icc compiler give different bench numbers from gcc -O3, I wonder if there are not rounding errors after some floating point computations and conversions to integer values.

[AndrewGrant]

I do not believe I make use of any floating point values, aside from when the Tuner is run.

I use some doubles when dealing with time on the clock, but those values are ignored when the benchmark is run

[Ras]

gcc -O3

That's another thing: O3 is not advised as it can well make the program slower. O2 is the usual optimisation level that doesn't backfire.

[abulmo2]

icc emits the following warnings for example:

Code: Select all

search.c(135): warning #2259: non-pointer conversion from "double" to "int" may lose significant bits
          margin =             1.6 * (abs(values[depth - 1] - values[depth - 2]));
                 ^

search.c(136): warning #2259: non-pointer conversion from "double" to "int" may lose significant bits
          margin = MAX(margin, 2.0 * (abs(values[depth - 2] - values[depth - 3])));
                 ^

search.c(137): warning #2259: non-pointer conversion from "double" to "int" may lose significant bits
          margin = MAX(margin, 0.8 * (abs(values[depth - 3] - values[depth - 4])));
                 ^

search.c(274): warning #2259: non-pointer conversion from "double" to "int" may lose significant bits
          futilityMargin = eval + depth * 0.95 * PieceValues[PAWN][EG];
                         ^

search.c(302): warning #2259: non-pointer conversion from "double" to "int" may lose significant bits
          value = eval - depth * 0.95 * PieceValues[PAWN][EG];

[AndrewGrant]

Thank you for this. I'll clean those up and see what happens.