Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
13th February 2020, 00:06 | #1 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Older compiler versions produce faster code?
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: 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? 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...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 13th February 2020 at 00:25. |
13th February 2020, 01:11 | #2 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I have noticed these differences with Intel C/C++ compilers. However, it very much depends on the code.
__________________
Groucho's Avisynth Stuff |
13th February 2020, 02:07 | #3 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Spectre mitigations in MSVC ??? [think it results in slower code]
https://devblogs.microsoft.com/cppbl...tions-in-msvc/
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
13th February 2020, 20:42 | #4 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 13th February 2020 at 20:50. |
|
19th February 2020, 17:24 | #5 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
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... |
27th February 2020, 08:11 | #6 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
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). |
27th February 2020, 13:01 | #7 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
27th February 2020, 23:11 | #8 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
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 and the mcf version here.
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.
__________________
My github. Last edited by jpsdr; 28th February 2020 at 11:07. |
28th February 2020, 00:33 | #9 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
BTW: I get almost exactly the same results with GCC 9.2.0 and GCC 5.4.0 on Linux. 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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 28th February 2020 at 00:43. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|