Submitted by GCC, the GNU Compiler Collection, version 4.1 has been released. The list of changes details the improvements. The Fedora team has already incorporated it and Fedora Core 5 will have 4.1 as the system compiler with GCC 3.2 provided as an alternative for compatibility reasons.
I’m eager to benchmark it against intel compiler now
The only reason why I purchase Intel CPUs is so I can compile my audio apps with their compiler, to get enormous performance boosts.
I use gcc weekly snapshots and must say that there is no any speedup in my own project and some other (x264 , MPlayer). May be 3.X -> 4.X changes are good for academic point of view but in real life there is no changes. May be I expect too lot from auto-vectorization and block reordering and dozens of other tricks?
I use gcc weekly snapshots and must say that there is no any speedup in my own project and some other (x264 , MPlayer). May be 3.X -> 4.X changes are good for academic point of view but in real life there is no changes. May be I expect too lot from auto-vectorization and block reordering and dozens of other tricks?
You are expecting way to much; for all the auto-vectorisation, there is only a limited amount that it can do – the rest unfortunately is good old fashioned manual optimisation.
Even if all the auto-vectorisation worked perfectly, the simple fact is, the amount one can squeeze out of optimisation only falls into the relms of single digit differences – hence the reason why Apple uses -Os rather than trying to using insane optimisation tricks when compiling their stuff; the possible risks of code buggerisation can’t be outweighed by improvements, be it real or perceived.
How do you know Apple uses -Os? Just curious.
How do you know Apple uses -Os? Just curious.
I asked
I downloaded Webkit source code, saw it compiling, logged onto the IRC channel, asked if I could change the default of -Os to something with a little more grunt, one of the Apple developers explained that the difference in performance wouldn’t be noticeable, and went on further to say that this was the case for the whole of MacOS X.
I always use -Os for embedded stuff and desktop programming. It generates smaller executables, especially for C++.
Many people don’t realize that -Os includes all the optimizations in -O2, which makes it fairly well optimized for speed anyway.
Really? I didn’t know this… thanks! Where did you find this out?
I’ve always preferred -Os because I like the smaller executable file size, and it does give some added speed benefits to no optimizations at all.
I don’t remember the exact page, but it was the main GCC docs on their website somewhere, where it talks about exactly what all the optimization levels do.
Basically, -O1 = no optimizations, -O2 = optimizations that speed up the program without increasing size, -O3 = O2 + stuff the does increase size, and -Os = O2 + stuff that reduces size (at expense of some speed). So Os may end up being slower than pure O2 because of the additional optimizations being done, but there is the additional speed you will get from a smaller executable.
Edit: Actually, I meant -00 = no opt., and -O1 = easy opts only.
Also, I looked again and -Os does disable a few of the O2 optimizations, but most of them are still enabled.
Ok, you’re right… just looked for it in the manual, it’s there. It says “-Os enables all of -O2 optimizations, except for ones that increase code size, and performs a number of size optimizations”
Anyway, compiled and tried it last night. It’s a tad slower compiling things than 3.4.4, but it does make executables smaller. I’m going to have to get used to some of the “smarter” warnings, too.
GCC 4.0, 4.1 and ICC 9 Benchmarks
http://gcc.gnu.org/ml/gcc/2005-11/msg01086.html
how long will it take the linux kernel to use this compiler version?
Is there a link/site which compares gcc with intel/VC++/borland?
how long will it take the linux kernel to use this compiler version?
My gentoo-sources kernel is compiled with a prerelease snapshot of GCC 4.1 – it works fine.
Kernel builds in Fedora Development are always compiled with the latest GCC snapshot, now the 4.1 release. Only a few minor errors encountered so far, according to Dave Jones.
Don’t know if you’ve already seen this, but there are a few reviews on GCC (up to version 4) at http://www.coyotegulch.com/reviews/index.html
Try this one: http://shootout.alioth.debian.org/
not all of them included, but there are many other programming and scripting languages as well.
the java support in gcj 4.1 is now complete enough to compile the Azureus bittorrent client to a native binary or use the jit runtime to execute the jar file. there are a few bugs, but that is still a pretty big milestone.
Is the QEMU-won’t-build bug still present?
Unfortunately, yes. It’s been broken since 4.0; but there are some patches available according to a Nov/2005 post on the mailing list: http://lists.gnu.org/archive/html/qemu-devel/2005-11/msg00245.html
Lots of stuff stopped building on gcc 4, QEMU is not alone.
Some things stopped building because of compiler bugs, most stopped because gcc 4 is much stricter.
1) Profile guided inlining.
— this would mean less bloated exe file, as the not frequently used code will not be inlined. For very large exe this could result in faster execution.
A new parameter min-inline-recursive-probability is also now available to throttle recursive inlining of functions with small average recursive depths.
— Less recursion inlining means faster code execution.
2) Analysis of references to static variables and type escape analysis, also forms of side-effects analysis. The results of these passes allow the compiler to be less conservative about call-clobbered variables and references. This results in more redundant loads being eliminated and in making static variables candidates for register promotion.
— static variable promotion, well again faster execution.
The rest of the things are out of my comprehensible limits. Maybe I need to learn more before I will be in a position to understand this.
However, there is one point if anyone could explain
A) GCC will now eliminate static variables whose usage was optimized out.
— Please explain this statement.
A) GCC will now eliminate static variables whose usage was optimized out.
— Please explain this statement.
I don’t know for sure, but I’d guess that refers to cases where the compiler can determine that a static variable is never actually used to pass a value from one function invocation to another.
Say you’ve got a programmer who can’t be bothered to declare “int i” in every function where he needs a loop counter, so he simply declares a global one. As long as i is initialised before use in every function (for(i=0;…)) and no i-using function is called while i is live, it can safely be turned into a local (register) variable.
Really though, such bad programming practice deserves an error message rather than a workaround optimisation.
The other possiblity I see is this:
You have a static variable used as a counter, or some other thing. You use this in your code, but after GCC optimizes everything, it finds that this static variable is no longer read from at any point in the program. Maybe you have a local variable that is always the same when it is being read? So it now completely removes the variable from the program instead of leaving it to take up memory.
This seems pretty obvious, though, so it is probably already being done. Unless it was just too difficult to remove static variables completely after you’ve gone through the optimization passes in GCC 3.x, which wouldn’t be too surprising either.
Fairly decent explaination.
Thanks man.
I wanted to vote for this answer, but voting is not enabled for me. Sorry cannot increase your score.
1) Profile guided inlining.
— this would mean less bloated exe file, as the not frequently used code will not be inlined. For very large exe this could result in faster execution.
If inlined code isn’t frequently used, surely the reduction in executable size is going to be negligible? After all, the compiler will only inline fairly simple functions so you’ll never have a huge inlined function to begin with.
I’d be interested in seeing what (if any) effect this new option has for performance and memory usage:
-fwhole-program –combine
Also if compilation time has gotten any better/worse than 4.0.
A new language front end for Objective-C++ has been added. This language allows users to mix the object oriented features of Objective-C with those of C++.
Ah, finally. Here’s to hoping this will help GNUstep get more software ported over from the world of Cocoa. The lack of ObjC++ in GCC’s main branch was a reason why porting WebCore was put on hold.
I guess this goes for any Gentoo user. I heard, not from any source that I really put any fait in, that using the GCC 4 toolchain would decrease the time needed to emerge your system. Is this true? If yes, why does 2006.0 use the GCC 3.x toolchain? Thanks.
why does 2006.0 use the GCC 3.x toolchain? Thanks.
There are still problems with GCC4 building some programs. Things are getting better but I still wouldn’t trust it to compile the whole system.
why does 2006.0 use the GCC 3.x toolchain?
Gcc 4.0 is much stricter than gcc 3.x in terms of what kind of c++ grammar it accepts. (And gcc 4.1 is even stricter than 4.0.) As a result, for many applications, gentoo devs had to create special patches so that gcc 4 would compile them. Making these patches can be hard. For example, rosegarden (a very popular midi sequencer) was only patched a week ago.
But it’s not enough to simply patch a package. By Gentoo policy, any non-security patches have to survive in the unstable (~x86, ~amd64 etc) tree for about a month before they can be considered stable (x86, amd64 etc). This is so that developers don’t accidentally destabilize the stable tree. And of course, LiveCD’s are prepared from the stable tree (since the unstable might have all sorts of weird stuff going on in it at a given moment in time.)
My guess is that there were enough non-gcc-4 compatible packages around in the stable tree when the 2006.0 release was being prepared that the developers decided to stick with gcc 3.4.