An interesting review and performance testing of the new GCC 4.
GCC 4.0 Review
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
An interesting review and performance testing of the new GCC 4.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
According to comments on Slashdot, Povray, which the author describes as a C++ application, is actually a C application.
Further, most of the examples in this review feature code likely to contain hand-tuned assembly, so it’s unlikely to benefit from compilation optimsations.
In addition to this -O3 doesn’t turn on a some of the auto-vectorisation stuff, so there’s some performance benefits missing there, too.
The author is right in saying that GCC 4.0 won’t bring any significant changes, it is laying the groundwork for further benefits down the road (in GCC 4.1 for example). However 4.0.1 should make the KDE developers happy, there’s a significant speed-up in compilation time:
http://www.kdedevelopers.org/node/view/1004
Unfortunately, KDE developers will have to wait till 4.0.1 as 4.0.0 has a bug (in register allocation I think) triggered by code in the KHTML codebase.
I undestand this after reading the article…I have not much data to contrast.
What is your experience with gcc 4.0?
Note that when using -O3, which includes -finline-functions, gcc doesn’t care about functions marked “inline” by the programmer. Thus it often makes code slower if the programmer knew what she was doing.
Speaking entirely in the hypothetical, without having tried it at all yet, in the grand OSNews.com tradition I’d say:
For C programmers, the review indicates your programs and compile times will be imperceptibly slower, so there is no great reason to upgrade.
On the other hand, this is no reason not to upgrade either.
Judging by the KDE blogs, C++ programmers will see a significant speed up in compilation time, so there’s a definite incentive to upgrade.
However 4.0.0 is just out the gate, and has bugs, so no-one should upgrade yet (wait for 4.0.1).
So it all depends on whether you’re a C or a C++ programmer. In any event, upgrading compilers is a serious enough task, personally I’d wait for the distros to iron out the bugs and package it.
Just wanted to know if the 4.0 is ABI compatible with the 3.X series.
I remember the major problem with upgrading from 2.X to 3.X was that the C++ binaries weren’t compatible (not even talking about the 3.0/3.1 versions…)
Are the changes here only internal?
The intel compiler statistics equally disappointed me. All the talk of their great compiler and it hardly produces results.You would think the intel compiler would blow away GCC but it hardly does.
Maybe we are reaching the limit of compiler technology and can not get any more optimizations for speed or code size.
The problem has a lot to do with language as well, C and C++ are really poor at passing a lot of a information to the compiler, less information, means less assumptions, means less optimizations
It is ABI compatible with 3.4 branch for C/C++
Apple choose GCC 4.0 for Mac OS X Tiger
Probably GCC 4 is more optimized for PowerPC G4/G5 than it was before (in contrast to similar performance for x86/AMD/…)
Some program compilation and benches on a 2.5 dual proc Mac system would be cool to have in terms of a comparison between the OSes.
A couple of points:
1) The C++ standard mandates that the “inline” keyword is a hint to the compiler to inline a function; i.e. -O3 or not, specifying a function with the “inline” keyword doesn’t guarantee that the function really will be inlined.
2) “Studies Show” ™ that frequently the compiler knows better than the user what should be inlined – even one who “knows what she is doing”.
Personally, I have never had the experience that -O3 has generated slower code for me (and I do consider that I “know what I am doing”…). As compilers get smarter, I have found myself phasing out use of the explicit “inline” altogether (ditto the “register” keyword).
Apple choose GCC 4.0 for Mac OS X Tiger
Probably GCC 4 is more optimized for PowerPC G4/G5 than it was before (in contrast to similar performance for x86/AMD/…)
At least Apple’s patched gcc. I doubt that the situation with their gcc patches is much better than with their khtml patches. Thus probably a big bunch of their patches haven’t found their way into upstream.
I doubt that ..
Thus probably ..
I don’t see the point posting such comments, unless you’re aim is to spread FUD about a company you obviously don’t like..
fear not doubters,
the old compiler system did not have cleanly decoupled intermediate stages, and in effect the frotn end had to know about the middle and back ends, doing away with the idea behind the separation. anyway – this led to optimisations from the front end – and obviously this has been refined over the years.
gcc4 has a new design and at this stage it is a stabel proof of concept – it works – but the potential for better and faster code has not yet been fuilfilled – so wait a while and the results will come.
I remember a year or so ago hearing a story from the Linux mailing lists. A developer found that some code (in the networking system, I think) that had a lot of inlines. He removed the inline declarations and…
…the code performed faster.
Why? Simple: the compiler did actually inline all the functions that were specified as “inline”. However this increased the size of the code (lots of duplicates) which led to cache misses. By reducing the number of inlines, he got all the code to stay in the cache, and thus it performed faster, even with the overhead of the function call.
Just something to think about.
but isnt this the bleeding edge stuff that everyone raves about and has to have asap! i will stick to the older, more developed, stuff myself, let the yougins run that new cool “look what i got” stuff….
🙂
LD wrote:
A couple of points:
1) The C++ standard mandates that the “inline” keyword is a hint to the compiler to inline a function; i.e. -O3 or not, specifying a function with the “inline” keyword doesn’t guarantee that the function really will be inlined.
2) “Studies Show” ™ that frequently the compiler knows better than the user what should be inlined – even one who “knows what she is doing”.
Personally, I have never had the experience that -O3 has generated slower code for me (and I do consider that I “know what I am doing”…). As compilers get smarter, I have found myself phasing out use of the explicit “inline” altogether (ditto the “register” keyword).
The thing is, I’ve just experienced the opposite happening with gcc 3.4, when using -O3 mind you. gcc chose to inline the wrong function, making the important one uninlinable, and incurring a performance loss of about 33%.
Some of the linux-kernel hackers seem to have issues with gcc’s inlining too:
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0707.html
Hopefully there will be better preformance in later versions of GCC 4.0. Have anyone here tested GCC 4.0 for themselves? I’ll stick with GCC 3.4 for a while i think.
http://bitsofnews.com & http://tech.bitsofnews.com
my fc4test/rawhide box’s seem to be running just fine.