APR
29
2005
|
gcc 4.0 C++ Compilation SpeedKDE sources now blacklist gcc 4.0.0 because it miscompiles KDE but that shouldn't be -O0 -O2 gcc 3.3.5 23m40 31m38 gcc 3.4.3 22m47 28m45 gcc 4.0.0 13m16 19m23 Next I compiled kdelibs/HEAD with --enable-final and unsermake -j 2: -O0 -O2 gcc 3.3.5 14m44 27m28 gcc 3.4.3 14m49 27m03 gcc 4.0.0 9m54 23m30 Finally the usual development case, same as above without --enable-final: -O0 gcc 3.3.5 32m56 gcc 3.4.3 32m49 gcc 4.0.0 15m15
I really like gcc 4.0's -O0 compilation speed improvement. :-) After the Subversion
|
![]() |
Comments
wow those are some interestin
wow those are some interesting results, cause seems like most of the complaints I hear against gcc is that each release it takes longer and longer to compile stuff, but obviously thats not the case here
Runtime
Have you tried any benchmarks of runtime performance of the different compilers? If GCC 4.0 really makes faster binaries, that's more important to the end-user.
Re: Runtime
No, I didn't try. gcc runtime performance is not annoying me and guess most people neither. Likely it's faster by some percent but not the same magnitude. :-) Application start performance and binary size whereas are better with gcc 4.0 because it allows KDE to prevent unnecessary exported symbols.
wow
The prospect of 50% less time waiting for my compiles to finish while developing is too good to be true! I have high hopes now and Arch has gcc 4 in testing...
> KDE sources now blacklist g
> KDE sources now blacklist gcc 4.0.0 because it miscompiles KDE...
Is this KDEs or GCCs failure?
How could it be KDE's failure
How could it be KDE's failure?
Conceivably the code could us
Conceivably the code could use deprecated/now-obsoleted features.
Then the compilation would ha
Then the compilation would have to fail and not silently produce broken code.
Indeed, if that's not the cas
Indeed, if that's not the case then it's certainly GCC's fault.