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.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th February 2020, 00:06   #1  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,160
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 13th February 2020 at 00:25.
LoRd_MuldeR is offline   Reply With Quote
Old 13th February 2020, 01:11   #2  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,032
I have noticed these differences with Intel C/C++ compilers. However, it very much depends on the code.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Old 13th February 2020, 02:07   #3  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 8,539
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 ???
StainlessS is offline   Reply With Quote
Old 13th February 2020, 20:42   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,160
Quote:
Originally Posted by StainlessS View Post
Spectre mitigations in MSVC ??? [think it results in slower code]

https://devblogs.microsoft.com/cppbl...tions-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.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 13th February 2020 at 20:50.
LoRd_MuldeR is offline   Reply With Quote
Old 19th February 2020, 17:24   #5  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 1,165
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...
FranceBB is offline   Reply With Quote
Old 27th February 2020, 08:11   #6  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,098
Quote:
Originally Posted by LoRd_MuldeR View Post

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).
filler56789 is offline   Reply With Quote
Old 27th February 2020, 13:01   #7  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,027
Quote:
Originally Posted by filler56789 View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 28th February 2020, 00:33   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,160
Quote:
Originally Posted by filler56789 View Post
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.

Quote:
Originally Posted by nevcairiel View Post
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.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 28th February 2020 at 00:43.
LoRd_MuldeR is offline   Reply With Quote
Old 10th April 2020, 19:03   #9  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,098
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)
filler56789 is offline   Reply With Quote
Old 27th February 2020, 23:11   #10  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,846
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.
jpsdr is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.