The best compiler for chess, Intel or gcc or something else?

[abulmo]

I found a bug too in icc 13.0

Code: Select all

unsigned int x = 1 << 24;
x = (x << 8) | (x >> 8);

with icc 13.0 x value is 0 instead of 65536.
Maybe you have similar code in your program, do you ?

I tried to signal this bug to intel, but I am not sure I sent it to the right email box. I once found a bug in gcc, sent it to the gcc-bugzilla, two days after the bug was fixed...

[ZirconiumX]

What did you optimize it with? I used -O3 and got my incorrect result.

Matthew:out

[diep]

For Diep -O3 is not faster than -O2 when using PGO with GCC 4.7.0

Hey Vincent,

How did Diep compiled w/ gcc 4.7.0 compare to ICC? Did it make up any of the advantage
that Intel had previously?

regards,
--tom

GCC 4.7.0 is 11% slower than some older intel c++ 11.0.x

Biggest difference is in 64 bits.

In both cases fastest compile is with just a simple -O2 and with PGO.
Stuff like flto in combination or any other combination as well as other options some suggested, they just slow down for GCC.

Am assuming the compilers do parameter tuning which option is best to optimize with, so would be weird if manual forcing of specific options speeds up of course.

Please note some old visual c++ from 2005 that with pgo it's not that much slower than intel c++, yet still faster than gcc 4.7.0.

That still means big progress for GCC as difference was dozens of percentages. Yet 7-11% is too much. It can't beat something from 7 years ago. Try that in computerchess.

Means you can't beat Fruit 2.1 single core getting 17 ply.
Note that GCC still is duck slow at AMD hardware. Above tests are at L5420 cpu.

[abulmo]

What did you optimize it with? I used -O3 and got my incorrect result.

The bug I quote appears at all optimization level. Compiler bugs that appear at a single optimization level are possible, but there is also (illegal) code that is sensitive to optimization levels, like pointer type punning, uninitialized variables, and any other construct with undefined behavior.

[diep]

I found a bug too in icc 13.0

Code: Select all

unsigned int x = 1 << 24;
x = (x << 8) | (x >> 8);

with icc 13.0 x value is 0 instead of 65536.
Maybe you have similar code in your program, do you ?

I tried to signal this bug to intel, but I am not sure I sent it to the right email box. I once found a bug in gcc, sent it to the gcc-bugzilla, two days after the bug was fixed...

What a BS about GCC. I posted code how GCC had been sabotaged with respect to branch optimization and 5 years later it still wasn't fixed as it would have speeded up back then GCC for AMD processors as well...

In fact we see todays GCC still sucks totally for AMD processors. How comes?

There is really no excuse for producing childish assembler code that's superslow for AMD if you use -march=opteron.

Yet it keeps on doing that.

GCC 4.7.0 is a lot faster than it was for intel processors yet it's still duck slow for AMD.

Main reason i would guess blindfolded is the inefficient sabotaged manner how it deals with branches.

If you use too many instructions a lot of those branches are still inside the 64 byte window of intel and outside the 16 byte window that AMD traditional used.

If you produce efficient code, AMD suddenly speeds up a lot... ...as such branches then no longer get a 20-30 cycle penalty or something yet close to zero (less than at intel).

but well this is the problem with teams of volunteers, if 1 company fails to sponsor such team, then the other companies dick it.

[rbarreira]

Vincent if you say GCC sucks on AMD, what is a better compiler for AMD?

Also:

http://developer.amd.com/tools/opensour ... fault.aspx

AMD recognizes that the GNU toolchain plays a critical part in the software development ecosystem, and therefore has been actively contributing to its evolution for over a decade. As far back as 2001, AMD developers and analysts have brought cutting edge code generation and reliability improvements for all x86 platforms to the GCC, glibc, binutils, GDB projects.

We feel strongly about our role, as a part of the greater open source community, to drive the quality and adoption of GCC and other components of the GNU project. AMD maintains close relationships with operating systems and compiler teams at major linux distribution vendors, as well as with GNU tools developers. These collaborations ensure that distributions include relevant GNU toolchain support for AMD platforms and help future-proof software products, and to analyze cutting edge instruction sets.

[Don]

Vincent if you say GCC sucks on AMD, what is a better compiler for AMD?

Vincent tends to be highly opinionated - but he is deal wrong about GCC being horribly slow, etc. Also he tends to use hyperbole to emphasize his points.

Sometimes he is right on the money, but for the most part you have to take what he says with a grain of salt.

Also:

http://developer.amd.com/tools/opensour ... fault.aspx

AMD recognizes that the GNU toolchain plays a critical part in the software development ecosystem, and therefore has been actively contributing to its evolution for over a decade. As far back as 2001, AMD developers and analysts have brought cutting edge code generation and reliability improvements for all x86 platforms to the GCC, glibc, binutils, GDB projects.

We feel strongly about our role, as a part of the greater open source community, to drive the quality and adoption of GCC and other components of the GNU project. AMD maintains close relationships with operating systems and compiler teams at major linux distribution vendors, as well as with GNU tools developers. These collaborations ensure that distributions include relevant GNU toolchain support for AMD platforms and help future-proof software products, and to analyze cutting edge instruction sets.

[rreagan]

In fact we see todays GCC still sucks totally for AMD processors. How comes?

So GCC sucks on AMD, and ICC sucks on AMD. Maybe AMD just sucks?

[rbarreira]

In fact we see todays GCC still sucks totally for AMD processors. How comes?

So GCC sucks on AMD, and ICC sucks on AMD. Maybe AMD just sucks?

Or maybe Vincent is wrong

Don Dailey yes I have become aware of that.

[diep]

Vincent if you say GCC sucks on AMD, what is a better compiler for AMD?

Vincent tends to be highly opinionated - but he is deal wrong about GCC being horribly slow, etc. Also he tends to use hyperbole to emphasize his points.

Sometimes he is right on the money, but for the most part you have to take what he says with a grain of salt.

Also:

http://developer.amd.com/tools/opensour ... fault.aspx

AMD recognizes that the GNU toolchain plays a critical part in the software development ecosystem, and therefore has been actively contributing to its evolution for over a decade. As far back as 2001, AMD developers and analysts have brought cutting edge code generation and reliability improvements for all x86 platforms to the GCC, glibc, binutils, GDB projects.

We feel strongly about our role, as a part of the greater open source community, to drive the quality and adoption of GCC and other components of the GNU project. AMD maintains close relationships with operating systems and compiler teams at major linux distribution vendors, as well as with GNU tools developers. These collaborations ensure that distributions include relevant GNU toolchain support for AMD platforms and help future-proof software products, and to analyze cutting edge instruction sets.

Facts speak for themselves:

GCC has a horrible PGO still. Wins just 7% on intel processors against icc winning 20-25% and visual studio wins 22%+.

Now where GCC 4.7.0 speeded up a lot compared to 4.4 / 4.5 series on intel hardware, i see no visible difference (or it must be somewhere around a 1% or less) between GCC 4.7.0 versus 4.4/4.5 on AMD hardware.

The reason is seemingly GCC prematurely rewrites simple branches to complex vehicles that afterwards do not get considered for the pgo to be optimized. yet this rewrite does slow down GCC on both architectures, AMD and intel, and especially on AMD get hit hard with it.

I'm guessing most bitboarders hardly have those branches.

I'm sure the reason AMD gets hit hard by GCC is the fact it just wins 7% with pgo. That's 7% at intel hardware, not at AMD hardware. 7% is very little. They have to pay a price for changing code into something objectively slower than it can be.

Even AMD's own compiler wins a whopping 30-40% with pgo.

GCC still is the same sabotaged compiler from AMD's viewpoint.

Now that AMD has a massive disadvantage in number of cores versus intel, that would no longer be needed i'd guess for intel to seem faster.

The pgo of ICC wins a whopping 25% for Diep on older K7 for example when using "p3 settings" at a bit older ICC versions.

I remember how old GCC's had a similar problem in terms of lagging behind. AMD then paid someone (if i remember well at SUSE) to improve the GCC compiler, which resulted in GCC's massive improvement from 3.x to 4.0+ within 1 year or so.

Maybe AMD should consider doing the same again instead of betting on their own compiler.