gcc4.8 outperforming gcc5, gcc6, gcc7

[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.

[abulmo2]

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.

I have always seen the opposite ie faster program with -O3. It seems to be the case with Ethereal too, at least on my computer (an old sandybridge, with gcc 6.3 and 7.2 under linux fedora 26 / 27).

[syzygy]

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.

I have always seen the opposite ie faster program with -O3. It seems to be the case with Ethereal too, at least on my computer (an old sandybridge, with gcc 6.3 and 7.2 under linux fedora 26 / 27).

Yes, and it would be rather strange if the gcc developers let -O3 enable known "de-optimisations".

Of course any particular optimisation can backfire for a particular program. Experimenting with different optimisation options will not hurt.

[AndrewGrant]

Upon cleaning those up...

I'll get the regular bench with the final PGO build, BUT during the profile-generate stage, I'll get a different bench.

Currently installing gcc7.2 from source on this machine so I can use -fsanitize=undefined...

[syzygy]

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

Compile with -fsanitize=undefined:

Code: Select all

search.c:386:47: runtime error: index -1 out of bounds for type 'int [9]'

search.c:386:

Code: Select all

            &&  quiets > LateMovePruningCounts[depth]

Apparently depth can be -1 in this line.

[AndrewGrant]

That would be because of the patch I pushed yesterday... to allow indexing that array when in check (which means depth could be < 0).

I'm surprised I don't get these errors when I run my program through valgrind / gdb