GCC 8.1 vs GCC 10.1

[Dann Corbit]

It is really important if you have a new AMD not to use defaults. The AMD CPU emulates some bit operations in software and the emulation code is not good, so you need to lie to the compiler and tell it you have a modern x86 CPU with SSE.
For evidence of this look at ipman's tests of AsmFish with BMI and with SSE on the Ryzen chips. You lose a horrid chunk of speed with a BMI compile.

[Gabor Szots]

Things are worse than I thought. I tried to compile the new Raven 1.00. With GCC 8.1 everything's OK. With GCC 10.1.0-3 I get a 200 kB error file, the start of which is this:

e:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\cicus\AppData\Local\Temp\cc4pmSs5.o (symbol from plugin):(.text+0x0): multiple definition of `posstack'; C:\Users\cicus\AppData\Local\Temp\ccDAWlqJ.o (symbol from plugin):(.text+0x0): first defined here
e:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\cicus\AppData\Local\Temp\cc4pmSs5.o (symbol from plugin):(.text+0x0): multiple definition of `posstackend'; C:\Users\cicus\AppData\Local\Temp\ccDAWlqJ.o (symbol from plugin):(.text+0x0): first defined here
e:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\cicus\AppData\Local\Temp\cc4pmSs5.o (symbol from plugin):(.text+0x0): multiple definition of `movestackend'; C:\Users\cicus\AppData\Local\Temp\ccDAWlqJ.o (symbol from plugin):(.text+0x0): first defined here
e:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\cicus\AppData\Local\Temp\cc4pmSs5.o (symbol from plugin):(.text+0x0): multiple definition of `totalendtime'; C:\Users\cicus\AppData\Local\Temp\ccDAWlqJ.o (symbol from plugin):(.text+0x0): first defined here

Etc.

Can it be the paths? My GCC 8.1 path is e:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\, while my GCC 10.1 path is e:\msys64\mingw64\bin\.

Or maybe GCC 10.1 is not properly installed.

[Ras]

Things are worse than I thought. I tried to compile the new Raven 1.00. With GCC 8.1 everything's OK. With GCC 10.1.0-3 I get a 200 kB error file, the start of which is this:

That's new with GCC 10 and actually caused by sloppy code. External variables should be declared as "external". Try compiling/linking with the "-fcommon" flag.

See also https://gcc.gnu.org/gcc-10/porting_to.html , first section.

[Gabor Szots]

Things are worse than I thought. I tried to compile the new Raven 1.00. With GCC 8.1 everything's OK. With GCC 10.1.0-3 I get a 200 kB error file, the start of which is this:

That's new with GCC 10 and actually caused by sloppy code. External variables should be declared as "external". Try compiling/linking with the "-fcommon" flag.

See also https://gcc.gnu.org/gcc-10/porting_to.html , first section.

The -fcommon flag worked. Thanks Rasmus.

[lucasart]

Things are worse than I thought. I tried to compile the new Raven 1.00. With GCC 8.1 everything's OK. With GCC 10.1.0-3 I get a 200 kB error file, the start of which is this:

That's new with GCC 10 and actually caused by sloppy code. External variables should be declared as "external". Try compiling/linking with the "-fcommon" flag.

See also https://gcc.gnu.org/gcc-10/porting_to.html , first section.

I'm shocked that GCC accepted such broken code before

Edit: just fixed my code

[AndrewGrant]

my experience is that gcc compiles are worse and more bloated than they were with older versions. Somewhere iaround GCC 4.6 we reached the golden age of gcc, we went downhill ever since, whereas LLVM is stronger than ever.

I too have had the same experience, although my "best" form is GCC4.8. For a long time I made sure to always use the older version, but I can say recently that GCC8/9 are able to compete once again. Although still a very worrying trend.

[Gabor Szots]

Thank you all for the replies.

[syzygy]

Right, those idiots try hard to make each new version of gcc slower than the one before. Fortunately we have expert-testers who expose them. Good job Gabor!

I switched to clang long ago and never looked back.

Though I did understand your irony on -s (which some people seem to confuse with -Os), my experience is that gcc compiles are worse and more bloated than they were with older versions. Somewhere iaround GCC 4.6 we reached the golden age of gcc, we went downhill ever since, whereas LLVM is stronger than ever.

For me, gcc-4.72/4.73 remained unbeatable for quite a while (until it stopped working due to changes in libraries or so).

But I cannot remember having ever seen clang beat gcc on speed of the executable. I tried once more very recently, and they were not even close.

[lucasart]

Right, those idiots try hard to make each new version of gcc slower than the one before. Fortunately we have expert-testers who expose them. Good job Gabor!

I switched to clang long ago and never looked back.

Though I did understand your irony on -s (which some people seem to confuse with -Os), my experience is that gcc compiles are worse and more bloated than they were with older versions. Somewhere iaround GCC 4.6 we reached the golden age of gcc, we went downhill ever since, whereas LLVM is stronger than ever.

For me, gcc-4.72/4.73 remained unbeatable for quite a while (until it stopped working due to changes in libraries or so).

But I cannot remember having ever seen clang beat gcc on speed of the executable. I tried once more very recently, and they were not even close.

It depends on the codebase. Indeed GCC compiles are faster than Clang for Ethereal, for example. But slower for Demolito. Here is a comparison for Demolito:

Compilation (same for both GCC and Clang):

Code: Select all

$ make CC=clang EXE=demo_clang
clang -march=native -std=gnu11 -DNDEBUG -O3 -flto -Wfatal-errors -Wall -Wextra -Wshadow -Wstrict-prototypes -Wsign-conversion -DVERSION=\"dev\" ./*.c -o demo_clang -s -lm -lpthread
$ make CC=gcc EXE=demo_gcc
gcc -march=native -std=gnu11 -DNDEBUG -O3 -flto -Wfatal-errors -Wall -Wextra -Wshadow -Wstrict-prototypes -Wsign-conversion -DVERSION=\"dev\" ./*.c -o demo_gcc -s -lm -lpthread

Speed benchmark, 3 runs each:

Code: Select all

$ ./demo_gcc bench|tail -4 && ./demo_gcc bench|tail -4 && ./demo_gcc bench|tail -4
seal  : e3ef8bcccf483111
time  : 5332ms
nodes : 12314404
nps   : 2309528
seal  : e3ef8bcccf483111
time  : 5282ms
nodes : 12314404
nps   : 2331390
seal  : e3ef8bcccf483111
time  : 5279ms
nodes : 12314404
nps   : 2332715
$ ./demo_clang bench|tail -4 && ./demo_clang bench|tail -4 && ./demo_clang bench|tail -4
seal  : e3ef8bcccf483111
time  : 5038ms
nodes : 12314404
nps   : 2444304
seal  : e3ef8bcccf483111
time  : 5051ms
nodes : 12314404
nps   : 2438013
seal  : e3ef8bcccf483111
time  : 5045ms
nodes : 12314404
nps   : 2440913

So Clang compile is 4.7% faster, on the median of 3 runs.

Fabien Letouzey reported the same thing with Senpai, where he recommends compiling with Clang, because GCC compiles were slower (I don't know if that's still true with recent versions). Note that Senpai is C++, not C.

[Ras]

Compilation (same for both GCC and Clang):

-O3 isn't always the fastest. What if you try -O2 instead?