Page 2 of 3
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 8:16 am
by 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.
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 12:41 pm
by 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.
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 1:03 pm
by Ras
Gabor Szots wrote: ↑Thu Jul 02, 2020 12:41 pmThings 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.
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 1:34 pm
by Gabor Szots
Ras wrote: ↑Thu Jul 02, 2020 1:03 pm
Gabor Szots wrote: ↑Thu Jul 02, 2020 12:41 pmThings 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.
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 2:20 pm
by lucasart
Ras wrote: ↑Thu Jul 02, 2020 1:03 pm
Gabor Szots wrote: ↑Thu Jul 02, 2020 12:41 pmThings 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
Re: GCC 8.1 vs GCC 10.1
Posted: Thu Jul 02, 2020 3:47 pm
by AndrewGrant
lucasart wrote: ↑Thu Jul 02, 2020 5:38 am
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.
Re: GCC 8.1 vs GCC 10.1
Posted: Fri Jul 03, 2020 8:38 am
by Gabor Szots
Thank you all for the replies.
Re: GCC 8.1 vs GCC 10.1
Posted: Fri Jul 03, 2020 5:28 pm
by syzygy
lucasart wrote: ↑Thu Jul 02, 2020 5:38 am
mar wrote: ↑Wed Jul 01, 2020 10:04 pm
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.
Re: GCC 8.1 vs GCC 10.1
Posted: Sat Jul 04, 2020 2:38 am
by lucasart
syzygy wrote: ↑Fri Jul 03, 2020 5:28 pm
lucasart wrote: ↑Thu Jul 02, 2020 5:38 am
mar wrote: ↑Wed Jul 01, 2020 10:04 pm
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.
Re: GCC 8.1 vs GCC 10.1
Posted: Sat Jul 04, 2020 9:04 am
by Ras
lucasart wrote: ↑Sat Jul 04, 2020 2:38 amCompilation (same for both GCC and Clang):
-O3 isn't always the fastest. What if you try -O2 instead?