GCC 8.1 vs GCC 10.1

[Gabor Szots]

Hi all,

I am not a programmer but still have successfully compiled some C or C++ engines using GCC 8.1. I have now installed GCC 10.1 and I noticed that the file sizes I obtain using it are much bigger than the ones made with 8.1. Also, the executables are slower.
I have an i5-4690K (Haswell) CPU and I mostly use the command gcc (or g++) *.c (or cpp) -O3 -march=native -o...

Is that only for me? Do you think I have to do something special?

[mhouppin]

Hi all,

I am not a programmer but still have successfully compiled some C or C++ engines using GCC 8.1. I have now installed GCC 10.1 and I noticed that the file sizes I obtain using it are much bigger than the ones made with 8.1. Also, the executables are slower.
I have an i5-4690K (Haswell) CPU and I mostly use the command gcc (or g++) *.c (or cpp) -O3 -march=native -o...

Is that only for me? Do you think I have to do something special?

I got same issues with gcc-10 on my machine, so I guess this new version still needs to be refined. For now gcc-9 seems the version that gives best performance and binary size.

[Ajedrecista]

Hello Gabor:

Hi all,

I am not a programmer but still have successfully compiled some C or C++ engines using GCC 8.1. I have now installed GCC 10.1 and I noticed that the file sizes I obtain using it are much bigger than the ones made with 8.1. Also, the executables are slower.
I have an i5-4690K (Haswell) CPU and I mostly use the command gcc (or g++) *.c (or cpp) -O3 -march=native -o...

Is that only for me? Do you think I have to do something special?

I am neither a programmer. Have you tried -s flag for size? I mean, compiling with -O3 -s instead of only -O3. It worked with older versions of GCC and G++ though I do not know if this flag still exists or has been removed. The size flag is listed as -Os under this blog article from 2019, which explains that -Os takes -O2 as the baseline.

I am clueless about the speed issue.

Regards from Spain.

Ajedrecista.

[Gabor Szots]

Have you tried -s flag for size? I mean, compiling with -O3 -s instead of only -O3. It worked with older versions of GCC and G++ though I do not know if this flag still exists or has been removed. The size flag is listed as -Os under this blog article from 2019, which explains that -Os takes -O2 as the baseline.

I am clueless about the speed issue.

Thanks, -s indeed helps a lot (tried with Achillees, it shrinks the size to 1/3. However, it slows down the executable considerably.

[mar]

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!

[Dann Corbit]

Did you remember to run strip after the compile finishes?
That usually reduces the size a lot.

If you build a static executable, it will be much larger than one that loads the DLL files dynamically. But if you do not link a static executable, you will have to have the DLL files available for the executables by putting them in the engine folder or the system path.

I get really good speed with GCC 10. What engine are you compiling?

I you are only going to run the binary on your machine, then set arch to native and do a profile guided build. Caveat: If you have a new AMD machine, then do NOT do a native build, but build only for an SSE target, because AMD does software implementation of some instructions and the software implementations are truly awful. PEXT is used by chess engines a lot and it is horrible on AMD, for instance.

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

[Dann Corbit]

For me gcc and llvm produce binaries that are approximately equivalent. Sometimes gcc is faster and sometimes llvm is faster.
I will say this, the llvm compiler diagnostics are the best on the planet. If for no other reason, it should be used for its lint like qualities.

[Gabor Szots]

Did you remember to run strip after the compile finishes?
That usually reduces the size a lot.

If you build a static executable, it will be much larger than one that loads the DLL files dynamically. But if you do not link a static executable, you will have to have the DLL files available for the executables by putting them in the engine folder or the system path.

I get really good speed with GCC 10. What engine are you compiling?

I you are only going to run the binary on your machine, then set arch to native and do a profile guided build. Caveat: If you have a new AMD machine, then do NOT do a native build, but build only for an SSE target, because AMD does software implementation of some instructions and the software implementations are truly awful. PEXT is used by chess engines a lot and it is horrible on AMD, for instance.

You mention things here which I don't really understand. No, I did not run strip. In fact size is not that important, speed is.
I have tried Achillees, Halogen, Monolith with 10.1.

[Ras]

Is -O2 faster? -O3 often bloats the code so that the optimisations turn out to be slower.