Older compiler versions produce faster code?

[LoRd_MuldeR]

I did a small performance test with a CPU-bound application that I'm currently working on and came to realize that older compiler versions seem to produce much faster code.

If we ignore that MSVC++ seems to fail miserably at generating x86 (32-Bit) code, the latest versions of both, MSVC++ and GCC, produce significantly slower code than the older versions of the same compiler:

https://i.imgur.com/X9BdW9m.png

Smaller is better. Each binary was measured 8 times, and only the fastest run was kept. Source code and compiler flags (especially things like "-O", "-march" and "-mtune") were the same for all compiler versions.

I know that this is just one specific application, so the results certainly can not be generalized. But any idea what's going on? :confused:

Do the latest compiler versions really contain serious performance regressions for this type of application, or did the defaults for some influential compiler settings change between the different compiler versions?

At least GCC has so many options and flags, that I have no idea, whether GCC 9.x can be tweaked to produce code as fast as GCC 5.x...

[Groucho2004]

I have noticed these differences with Intel C/C++ compilers. However, it very much depends on the code.

[StainlessS]

Spectre mitigations in MSVC ??? [think it results in slower code]

https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/

[LoRd_MuldeR]

Spectre mitigations in MSVC ??? [think it results in slower code]

https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/

I don't think so, because the /Qspectre option is off by default. Using this option even requires to install a special component from VS installer (Spectre-mitigated libraries) or the build will fail, as I just figured out ;)

Anyway, even with /Qspectre explicitly enabled, VS2019 performance is the same as before – didn't degrade any further. And, either way, VS2019 produces way slower x64 code than VS2010.

[FranceBB]

Interesting...
I didn't expect an older version to produce faster code.
By the way, I wonder how Intel Parallel Studio performs when it compiles the same code...

[filler56789]

https://i.imgur.com/X9BdW9m.png



Regarding the GCCs you used in that experiment...

are all of them win32-threaded?
OR posix-threaded?
OR the old ones are win32-threaded and the new ones posix-threaded?
(or vice-versa?)

At least according to some comments made by nevcairiel "years ago",
the threading model used by GCC should affect the compiler's performance
(i.e., winpthreads suxxx).

[nevcairiel]

At least according to some comments made by nevcairiel "years ago",
the threading model used by GCC should affect the compiler's performance
(i.e., winpthreads suxxx).

This only really matters if you use compiler-controlled threading primitives, like std::threads (which aren't supported on mingw64-gcc anyway for some reason), or OpenMP, and I believe winpthreads also got better since those days.

[jpsdr]

A little while ago, i've made the following encode speed test, comparing gcc with mcf, winthread or posix thread model, on the 9.2.1 version. The posix was the one provided with msys2, the winthread version here (http://msystem.waw.pl/x265/) and the mcf version here (https://gcc-mcf.lhmouse.com/).
mcf was faster than winthread which was faster than posix. But if was each time around 3 minutes for an 2 hours encode.
The x264 was compiled with the posix thread option with the posix gcc, and with the win32 thread option for the winthread and mcf gcc.

This post made me make a little test, comparing 9.2.1 mcf gcc with 5.5.0 and 4.9.4 winthread gcc (from the links i provided).
x264 was compiled with the win32 thread option (on configure), and gcc had AVX2 option and Broadwell tuning option, targeting x64.
I've encoded a 3000 frames small video, encoding time results are :
GCC 4.9.4 : 11m45s
GCC 5.5.0 : 11m44s
GCC 9.2.1 : 11m43s
So... very similar results...

Edit : forget to tell, build was also fprofiled. Test was under Windows 7 x64.

[LoRd_MuldeR]

Regarding the GCCs you used in that experiment...

are all of them win32-threaded?
OR posix-threaded?
OR the old ones are win32-threaded and the new ones posix-threaded?
(or vice-versa?)

On Windows, all GCC versions used were Mingw-w64 (via MSYS2), which I think uses libwinpthread. But the application under test doesn't use threads anyway.

BTW: I get almost exactly the same results with GCC 9.2.0 and GCC 5.4.0 on Linux.

std::threads (which aren't supported on mingw64-gcc anyway for some reason)

I think Mingw-w64 with "posix" threading-model (the one that depends on libwinpthread) does support std::threads, whereas Mingw-w64 with "win32" threading-model doesn't.

[filler56789]

F.W.I.W.:

Android 8.1 "GO" Edition is compiled with GCC 4.8.x 0_o

(on my puny Samsung Galaxy J4 Core at least)