OSNews

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.

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?

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.

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.

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.

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.