A Review of GCC 4.0

ChaoticCoyote writes " I've just posted a short review of GCC 4.0, which compares it against GCC 3.4.3 on Opteron and Pentium 4 systems, using LAME, POV-Ray, the Linux kernel, and SciMark2 as benchmarks. My conclusion: Is GCC 4.0 better than its predecessors? In terms of raw numbers, the answer is a definite "no". I've tried GCC 4.0 on other programs, with similar results to the tests above, and I won't be recompiling my Gentoo systems with GCC 4.0 in the near future. The GCC 3.4 series still has life in it, and the GCC folk have committed to maintaining it. A 3.4.4 update is pending as I write this. That said, no one should expect a "point-oh-point-oh" release to deliver the full potential of a product, particularly when it comes to a software system with the complexity of GCC. Version 4.0.0 is laying a foundation for the future, and should be seen as a technological step forward with new internal architectures and the addition of Fortran 95. If you compile a great deal of C++, you'll want to investigate GCC 4.0. Keep an eye on 4.0. Like a baby, we won't really appreciate its value until it's matured a bit. "

Comments

I'll tell you what the problem is...

[Anonymous Coward]

Well clearly the problem is that you compiled GCC 4.0.0 with GCC 3.4.3! What I did was go through the GCC 4.0 source code in two seperate windows, fire up hexedit in another, and go through line by line "compiling" GCC 4.0 with the GCC 4.0 source, in my head. I wouldn't recommend doing this with -funroll-loops, my hands started cramping up.

Or you could wait to compile 4.0 until the 3.0 branch makes it to 3.9.9, then it will be close enough anyway. YMMV, people say I give out bad advice, go figure...

Re:I'll tell you what the problem is...

[Inkieminstrel]

Gee, I would have just compiled 4.0.0 with 3.4.3, then compiled 4.0.0 again with 4.0.0.

Re:I'll tell you what the problem is...

[DJCacophony]

but then the gcc 4 you compiled with gcc 3.4.3 would produce tainted compilations, and the second 4.0.0 compilation would lean towards 3.4.3 because it was compiled with a compiler that was compiled by 3.4.3. You would have to then take the second compilation of 4.0.0 and compile 4.0.0 with it, at which point the similarity to 3.4.3 would make it somewhere along the lines of 3.7.0. If you continue to compile it, while it will never reach 4.0.0, it will approach closely enough that for all intents and purposes, it will be 4.0.0. The forumula is as follows:

V3-V1~2(V3-V2)

where V1 was used to compile V2, and V2 was used to compile V3.

Re:I'll tell you what the problem is...

[Anonymous Coward]

This was meant as a joke, but for those who took this too seriously: if you have ever tried building GCC yourself, you should know that it always recompiles itself.

A gcc "stage 1" build is gcc compiled with your old compiler. The "stage 2" build is gcc compiled with the compiler created in the previous stage. This is the one that gets installed. The "stage 3" build is optional and verifies that the "stage 2" compiler creates the same output as the previous one.

Re:I'll tell you what the problem is...

[confused one]

I believe the Linux from Scratch (LFS) folks have found you have to repeat this three (3) times to have, what is effectively, a clean 4.0.0 compile.

Re:I'll tell you what the problem is...

[Anonymous Coward]

Nice try. When you build GCC you do a "make bootstrap", which does things in multiple stages:\
1- Compiles 4.0 with system compiler (3.4.3) and no optimizations
2- Compiles 4.0 with stage 1 compiler, full optimization
3- Compiles 4.0 with stage 2 compiler, full optimization.
4- Checks that stage 2 and 3 produced the same code. Results of stage 3 is the final compiler.

(I might be missing a stage there)

Modern GCCs even have a bootstrap target that adds an extra stage where GCC is profiled, to see which branches are taken more often, and the results are fed back into the next stage so the compiler is optimized for real world usage. Nice stuff really.

Re:I'll tell you what the problem is...

[Anonymous Coward]

Nice try? Uh, I think the parent post was a JOKE... Here, this might help.

Re:I'll tell you what the problem is...

[TelJanin]

Unless one of them produces faulty code, compiling 4.0 with 4.0 compiled with 3.4 will suffice.

Re:I'll tell you what the problem is...

[Anonymous Coward]

I hear you. I have actually had to turn that off for at least one instance. "make bootstrap" doesn't work if you are trying to build for another platform (I.E. compiling on i686 for i586). The hardest thing however was trying to convince gcc to build for the target platform rather than the source platform, and ending up with a "reverse cross compiler".

Re:I'll tell you what the problem is...

[rsidd]

The GP was a joke, but since you're serious, this is exactly what the "bootstrapping" build of gcc does: it builds a stage 1 build with the system compiler, then a stage 2 build with the stage 1 build, then -- if you want -- a stage 3 build with the stage 2 build, and verifies that the stage 2 and stage 3 builds are the same.

Re:I'll tell you what the problem is...

[m50d]

I think you've missed out a stage. Gcc builds a "subcompiler" to compile itself with, then once compiled with that it uses itself to recompile itself. Maybe that's stage 0?

Re:I'll tell you what the problem is...

[inode_buddha]

Sorta like LFS if you remember to chroot and remove the deps properly

Re:I'll tell you what the problem is...

[Anonymous Coward]

But if the system compiler is GCC, and you use it in stage 1, what's the point of comparing?

Isn't it possible that the compiler knows when its compiling itself, and changes its output appropriately? Such as adding the backdoor to login(), etc.?

Re:I'll tell you what the problem is...

[scum-e-bag]

The compilation of GCC 3 times is part of a process to create a toolchain. The toolchain dereferences the host system. By creating a seperate toolchain it is hoped that all hard coded reference to the host system are removed when building the final LFS system. This allows the creation of the LFS system that will not crash when a hardcoded path from the original host is referenced.

Re:I'll tell you what the problem is...

[Anonymous Coward]

But if the system compiler is GCC, and you use it in stage 1, what's the point of comparing?

Versions. Afterall, why should a previous version of gcc be considered any more acceptable than any other compiler?

Re:I'll tell you what the problem is...

[Anonymous Coward]

No, no no. To erase the taint you have to create antitaint.

gcc40_by34 = gcc34.compile(gcc40.src());
gcc34_by40 = gcc40_by34.compile(gcc34.src());

gcc40_by34_by40 = gcc34_by40.compile(gcc40.src());
gcc40_taintfree = gcc40_by34_by40.compile(gcc40.src());

Then its just a series of compiles to apply the antitaint.
Everybody knows that!

Re:I'll tell you what the problem is...

[chrish]

The problem is that you're testing one CPU architecture only; gcc 4 has lots of improvements for non-x86 platforms (PowerPC, for example).

Expected

[Hatta]

It was a long time before GCC 3 got better than 2.95. I expect the same thing will happen here.

Re:Expected

[guyfromindia]

Very true!

Re:Expected

[Rei]

I think the problem is that, if I'm not mistaken, he's testing all C code except Povray. The biggest reported improvements in 4.0 were for g++, so using such a small C++ sample base (Povray - one purpose, one set of design principles, few authors) seems bound to produce inaccurate benchmarking.

Further, on his most reasonable C benchmark (the Linux kernel), he only records compile time and binary size, but no performance. I call it the most reasonable benchmark because it has thousands of contributors and covers a wide range of code purposes and individual coding habits - and yet, performance is omitted.

In short, I wouldn't trust this benchmark. Probably the best benchmark would be to build a whole Gentoo system with both, with identical configurations, and check build times and performances ;)

Re:Expected

[ajs]

I'm not convinced that this test shows that gcc4 is less effecitve than gcc3, though.

First off, all of the programs tested are programs that use hand-tooled assembly in the most performance-sensitive code. That has to mean that the compiler is moot in those sections.

A better test would be to compare three things: the hand-optimized assembly under gcc 3 vs the C code (usually there's a configure switch that tells the code to ignore the hand-tuned assembly, and use a C equivalent) under gcc4 vs that same C code under gcc4.

I think you'd see a surprising result, and if the vectorization code is good enough, you should even see a small boost over the hand-tuned assembly (since ALL of the code is being optimized this way, not just critical sections).

Re:Expected

[markov_chain]

Is it that surprising that a Gentoo user thinks of compiling time as the performance metric? :)

Re:Expected

[Rimbo]

I think the author of the article misunderstands just what happened with GCC 4.0.

The main improvement in GCC 4.0 is implementing Single Static Assignment.

SSA is not an optimization. It is a simplification. If you can assume SSA, then it opens the door to an entire class of optimizations that can help improve your performance without affecting your code's correctness.

That last bit -- optimizing code without affecting correctness -- was a big problem in the days before SSA.

In that regard, SSA is a similar technology to RISC -- it does not speed things up by itself, but it enables speedups for later on.

The lack of SSA is one thing that kept gcc out of the hands of compiler researchers. Now that it does that, academia can start hacking away with gcc, and the delay you expect is the time between implementing SSA and implementing all of the optimizations that really will improve code performance.

Re:Expected

[The boojum]

Sorry to tell you this, but the review is even mistaken with respect to Povray. Povray is not a C++ program - it's good ol' C. So in fact, none of the programs he benchmarked were C++. The test was exclusively on C code.

As nice as C is, a lot of the improvements in GCC seemed to have been targetted at improving its handling of C++ code. I'd particularly like to know how it fairs with respect to modern C++ style code - massively templated stuff with STL, Boost, traits and policies, smart pointers, lots of small inlined methods, etc. This test tells me nothing about that, and that's where a lot of development is these days.

Re:Expected

[Shisha]

I call it the most reasonable benchmark because it has thousands of contributors and covers a wide range of code purposes and individual coding habits - and yet, performance is omitted.
As someone who has done some kernel (see this old project) and other programming, I would probably disagree with this statement. The code you find in the linux kernel is rather different (think concurrency, locking, I/O waiting, message passing) to the code you'd find in a number crunching application (think for loops that take forever, huge data sets, nested recursion) which would be rather different to the code you find in something like LAME (think DSP code).

As for the coding habits, the kernel develoment process encourages similar coding habits as it makes the code easier for others to read. There would be differences between different subsystems, which brings us to another problem: where do you start benchmarking the kernel as a whole?

Re:Expected

[Anonymous Coward]

As a Gentoo user, when I heard gcc 4 would compile c++ code 25% faster, my heart leapt out of my chest.

Re:Expected

[lpp]

GCC 4.0.0 can't be all that bad. After all, that's one less Gentoo user I have to listen to go on about how awesome their uber-tweaked system is.

Re:Expected

[uid8472]

POVray used to be written in plain C, but recent versions -- 3.5 and later, I think -- use C++.

Re:Expected

[ma_luen]

I think you are over estimating the interest of the research community in working on gcc. The move from the intentionally underdocumented and ill defined intermediate representations to tree ssa is a huge step for gcc. Unfortunately, there is still no real effort to make the platform attractive to do experimental work on.

The McCat compiler from McGill (which is what gcc borrowed the ssa rep from), C-- or the LLVM project all provide a much nicer platform. The internal representation is clearly documented, there are frameworks and examples for writing new passes and most importantly they all allow for whole program compilation.

Until gcc decides to support some of this the project will continue to be ignored by research groups. This might be fine since research compiler work can be fairly ugly and it is just easier to port what works.

Otherwise I agree that the move to ssa form is a critical step for gcc to take and it will enable it to become a "modern" compiler. More emportantly it will enable the inclusion of the large body of compiler work that is based on ssa forms.

Mark

Re:Expected

[Anonymous Coward]

I also wouldn't trust this.
The author is using kernel version 4.6.11.8, which is very well known for it's bad performance with GCC4 binaries specifically.

(Hint: Look at the kernel version compiled in the benchmark)

Re:Expected

[Rimbo]

Good point. Perhaps it's more accurate to say that gcc was made less unattractive to compiler researchers. :)

Re:Expected

[labratuk]

I think you'd see a surprising result, and if the vectorization code is good enough, you should even see a small boost over the hand-tuned assembly

GCC 4.0 doesn't have autovectorisation enabled because there aren't yet any heuristics to tell it when the vectorised code will be faster than the normal code.

Re:Expected

[prell]

I wonder how well Apple's gcc 4.0 (in Tiger) fairs?

Re:Expected

[cjameshuff]

That is true, but most of the code is still C-style. Aside from a few newer portions, it is basically a C program compiled as C++. It is definitely not a good representative of typical C++ programs.

Re:Expected

[zoefff]

My lord, I...I'd say ...Kentoo! Amen!

Re:Expected

[iabervon]

The article actually says that 4.0.x will probably beat 3.4.x before long, and the reason for this is really Tree SSA. However, that doesn't mean it makes sense to actually compile things with a compiler which is lousy, but about to improve rapidly. His conclusion is that 4.0 doesn't take enough advantage of the new design to make it worthwhile to end users yet.

(Incidentally, the improvement isn't actually "SSA", but "Tree SSA"; that is, they're doing SSA at a higher level, which enables optimizations to be done with more information. Earlier versions did use SSA in implementing optimizations, but it was in the back end, not in the IR. This means that optimizations can be done more generally and easily.)

Re:Expected

[Adam Avangelist]

True. However the Gentoo version of gcc 3.4.3 contains the visibility options native to gcc 4. So when he says he will not switch, he still has good reason to stay with gcc 3.4.x series.

Re:Expected

[Anonymous Coward]

I'd particularly like to know how it fairs with respect to modern C++ style code - massively templated stuff with STL, Boost, traits and policies, smart pointers, lots of small inlined methods, etc.

Even then, a lot of current code is optimized for existing compilers. For example, GCC 4.0 finally includes full-blown scalar replacement of aggregates, so struct members can be accessed with less overhead when accessed repeatedly (as oposed to reloading address and offset). This makes a lot of difference in heavy templated code with lots of iterators. OTOH, GCC has included a simpler version since 2.95 at least, which does something similar for structs with a single member, like most of the STL iterators.

So in this case, if you use code that only uses STL iterators, you won't see any improvement (as there was already no abstraction penalty), so you have to choose benchmarks carefully. Likewise you might run into a lot of code that avoids unoptimized constructs. Like passing and returning pointers to avoid depending on constructier ellision and NRVO.

Smart pointers are something I'm very interested in and will be checking out as soon as I clear out enough space to build a cygwin binary. Modern smart pointers (boost::smart_ptr or std::tr1::smart_ptr) have more than one member, so scalar replacement of aggregates should be really nice in terms of execution speed.

And at some point I'll play around with the new lambda libraries. Should be nice to implicitely build up a function inside the parameter list of a transform :)

Re:Expected

[Jerf]

If anyone wants a suggestion for a counter-benchmark, I suggest LyX; I used to run Gentoo on a Pentium 133 w/40MB of RAM*. LyX is the only program that I couldn't compile on that; the C++ it uses made GCC consume too much memory. Even Mozilla could compile on that. It's slow even on modern machines out of proportion to the source code size.

*: It was a sane decision at the time. I tried Debian on it and it was significantly slower. This was before all the distros distributed i586 binaries, and the Pentium speedups were significant well beyond perceptual bias (we're talking three or four times faster to start up enlightenment, for instance, and tolerable performance vs. completely unacceptable performance for window painting and such). 133MHz pentiums need all the help they can get. I'd never do that now.

Re:Expected

[Mornelithe]

If you're testing the performance of a compiler, it is one possible metric.

As I recall, many KDE developers stuck with GCC 2.95 for development long after 3.x was out, because 3.x compiled C++ significantly slower. It isn't merely a concern for Gentoo users.

Should we all start making cracks about, "is it that surprising that people at Pixar use rendering time as a performance metric?" Boy, that's hilarious.

Re:Expected

[Rimbo]

Correct. I was being lazy. :)

Re:Expected

[Sloppy]

That's why I have -heartleap in my USE flags.

Re:Expected

[ajs]

-ftree-vectorize works fine.

Re:Expected

[Anonymous Coward]

Did anyone stop to think how dumb it is to benchmark the speed of compiling? And that the GP specifically mentioned the performance of the system's use?

AFAIK, vectorizing will make the compiling slower, but actual use faster. And there's no better way to get a fully GCC 4.0 system than compile it yourself. But no, gentoo bashing, for some strange reason, is as popular as MS bashing.

What about...

[elid]

...Tiger? Wasn't it compiled with GCC 4.0?

Re:What about...

[Anonymous Coward]

Most likely the author is using x86...

The parent does bring up a good point: What about benchmarks on the G5 architecture? Apple was who made 4.0 happen...

Re:What about...

[scotlewis]

Yes and no. The default compiler is GCC4, however, the kernel and much of the OS (pretty much all of Darwin, in fact) are still compiled with GCC3 because they haven't completely cleared the codebase of GCC3-isms.

That said, remember that the submitter is talking about GCC4 on x86 platforms, and remember that Apple is putting a lot of work into making sure the PowerPC optimizations are as good as possible. Not to mention things like GCC4's auto-vectorization of code to take advantage of the Altivec unit (which has a more noticeable effect than MMXing x86 code).

It would be nice to see some test results for Apple's GCC versions 3 and 4.

Re:What about...

[Anonymous Coward]

Ok, I dusted off the

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

I just got Tiger. I used the existing binary that I compiled under Panther (gcc3) and compiled a new binary (gcc4). Overall results, gcc3:

INTEGER INDEX : 29.124
FLOATING-POINT INDEX: 17.430

gcc4:

INTEGER INDEX : 32.285
FLOATING-POINT INDEX: 17.553

So floating point is identical, for integer there is a ~10% speedup. It's interesting to see that the NUMERIC SORT test is a bit slower under gcc4: 13.8 rather than 14.96 times the reference system (MSDOS Pentium 90 Wacom compiler). The biggest speedups are STRING SORT (68.37 / 58.21), IDEA (43.85 / 36.86) and HUFFMAN (29.21 / 21.92).

Re:What about...

[Space cowboy]

It would be nice to see some test results for Apple's GCC versions 3 and 4.

Well, I did have a bunch of results for you, but the CRAPPY LAMENESS FILTER won't let me post them. Apparently I have to use less 'junk' characters (of course the CRAPPY PROGRAMMER didn't define what a 'junk' character is in the error message, so that's NO USE WHAT-SO-EVER.)

So, I guess I'll summarise. gcc version 4 is slightly worse than 3.3, and slightly better when the tree-vectorize option is passed and altivec code is generated.

Simon

GCD~?

[essreenim]

No, the problem is we need D jk. But really, is anybody taking D seriously? here

Re:GCD~?

[pclminion]

No, the problem is we need D jk.

Okay, I must be a total fucking geek, because at first I thought you had abbreviated "Dijkstra" as "Dijk" and left the 'i' out for some reason. Then I wondered why the hell Dijkstra would waste his time compiling code by hand...

Re:GCD~?

[essreenim]

Sorry, D jk means D j.ust k.idding. Actually, Im wrong anyway as it is GCC (GNU compiler collection or something. so it would stil be GCC. Anyway, boring story really...

The performance of compiled code

[pclminion]

This has always bugged me.

Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.

Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.

To semi-quote The Matrix: One of these endeavors... is intelligent. And one of them is not.

Re:The performance of compiled code

[GoCoGi]

Combine a) with b).

Re:The performance of compiled code

[Chirs]

At some point you've got the best algorithm, you've profiled, you've hand-optimised, you've got the fastest hardware you can afford....and you *still* need that last 5%.

That's when you spend 10 hours tweaking compilers settings...

Re:The performance of compiled code

[pclminion]

At some point you've got the best algorithm, you've profiled, you've hand-optimised, you've got the fastest hardware you can afford....and you *still* need that last 5%. That's when you spend 10 hours tweaking compilers settings...

If you really, positively need an extra 5% performance, you might as well just buy a computer that's 5% faster.

Re:The performance of compiled code

[Jeremy.DeGroot]

You should do both. Choosing the right algorithms is crucial, no doubt about it. But if you've got a massive database application, that 5% can represent a huge amount of work and be worth the trouble. A little bit of extra performance can, in many cases, go a long, long way towards adding to the value of the software. Both endeavors are intelligent in many (if not most) cases. Performance is important in software, and any little bit you can squeeze out will likely be a big deal.

Re:The performance of compiled code

[CoderBob]

Didn't he say "You've got the fastest hardware you can afford"?? There's no guarantee that the hardware will help, either. Some OSes **cough**Windows**cough** seem to like not using hardware effectively.

Re:The performance of compiled code

[Stiletto]

If you really, positively need an extra 5% performance, you might as well just buy a computer that's 5% faster.

You work at Microsoft, right? No? Intel?

Re:The performance of compiled code

[Minwee]

Unfortunately, including a faster computer with every copy of the code you distribute may be prohibitively expensive.

Re:The performance of compiled code

[Anonymous Coward]

If you really, positively need an extra 5% performance, you might as well just buy a computer that's 5% faster.

Why should they? What problem do you have how someone spends their time? If someone wants to make their system as fast as they can, that's their business.

You're obviously a small box user. Have you ever worked in the real world where huge batch runs can take weeks? You think companies should splash out another million or too on new hardware, just because you use a pissy little machine?

Re:The performance of compiled code

[kfg]

And in both groups you will find people who believe that execution speed is the measurement of code quality.

KFG

Re:The performance of compiled code

[putko]

When you are dealing with expensive hardware, or a cluster, buying more hardware is likely a lot more expensive than optimizing the software.

E.g. buy 500 faster CPUs? Buy some more CPUs? If the CPUs cost enough and take time to order, optimizing the software might be the easy way out.

Re:The performance of compiled code

[pclminion]

You're obviously a small box user. Have you ever worked in the real world where huge batch runs can take weeks?

Yes.

You think companies should splash out another million or too on new hardware, just because you use a pissy little machine?

I think that companies should re-evaluate their "need" for an extra 5% performance. Here's an idea -- if you need something 10 minutes faster, why not start the process 10 minutes sooner?

5% just gets lost in the noise. You beef up your system, making it 5% faster... And then some retard in production makes a mistake and sets you back six weeks.

Re:The performance of compiled code

[pclminion]

When you are dealing with expensive hardware, or a cluster

If you're dealing with a cluster, chances are you can make improvements significantly larger than 5%.

Re:The performance of compiled code

[mattgreen]

It is because it is easier to delve into needlessly technical aspects afforded by compiler settings and 'optimizations' than it is to admit that one's algorithm is not sound. Kids running Gentoo delude themselves into thinking that omitting the frame pointer on compiles is going to make a massive difference in terms of performance, and fail to remember it makes bug hunting far more difficult when applications crash. Additionally, the 5% gain mentioned can be a severe overstatement. I frequent a game programming board, and the widespread use of C++ has led to an abundance of nano-optimization threads, the most amusing of which was an attempt to optimize strlen().

Optimizing every single line of code is a complete waste of time, since the 80/20 rule generally applies. Use a profiler to determine where that 20% is.

Re:The performance of compiled code

[The Snowman]

I think that companies should re-evaluate their "need" for an extra 5% performance. Here's an idea -- if you need something 10 minutes faster, why not start the process 10 minutes sooner?

In any large organization, the process gets in the way. Some suit decides the product needs a new feature, or needs to ship sooner, or whatever, and this slowly trickles down to the developers who suddenly are put in crunch time where every minute counts. Schedules and deadlines may change daily. People's jobs may be at risk. Shit happens.

Nobody really likes it, but that is sometimes how we arrive at the point where we "need" an extra 5% performance, where we "need" the program to finish ten minutes sooner. Starting earlier is not always an option, usually because you don't know you even have to start *at all* until the last minute.

Re:The performance of compiled code

[Avenger337]

I disagree -- 5% can be a LOT, particularly if you're running something that takes an incredibly long time

Sure, maybe your 3.5 hour process only runs 10 minutes faster -- but on the other hand, your 10-week-long simulation of quantum physics finishes several days sooner. 5% is a lot.

Re:The performance of compiled code

[mattgreen]

Probably because execution speed is objective and therefore suitable for chest-thumping. You do not see nearly as many people advertising the clarity of their code in the same way.

(Well, maybe the Java crowd at times, but they tend to confuse having only one way to do things with clarity.)

Re:The performance of compiled code

[Anonymous Coward]

If you really, positively need an extra 5% performance, you might as well just buy a computer that's 5% faster.

To see the problem with that reasoning, ask yourself this question: when should you first apply it? Are you sure that now is a good time?

Progress in compiler optimization is made in increments of 5% or less. If you dismiss insignificant-sounding optimizations in favor of waiting for the next big breakthrough, you will find that those breakthroughs are few and far between.

At this point, the low-hanging fruit has all been picked. It's incrementalism or nothing.

Re:The performance of compiled code

[IHateSlashDot]

The point of this article is compiler optimizations, not algorithm selection. At the point that I look at compiler performance, I've already done all of the algorithm tuning so your point is moot. This is a very interesting benchmark for those that of who already write good code and want the compiler to make the best of it.

Re:The performance of compiled code

[hackstraw]

Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.

Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.

Yeah, I know what you mean.

Some people that are really concerned about performance go out and get a real compiler to compile their codes. For the x86 platform there is the PathScale, Intel, and Portland Group compilers. Its not uncommon for these to give 100% speedup over GCC. These other compilers are required if you have codes in Fortran because g77 simply does not cut it.

Re:The performance of compiled code

[leonmergen]

Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.

Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.

True, true... but still, you need a compiler to optimize your code. I find it a blessing that my compiler finds out the best way to inline certain functions for me, that i can just define a function as 'const' when it is const to provide the compiler with information to optimize with, etc etc...

Sure, you might not need compiler optimizations, but to be bugged with compiler optimizations is just silly...

Re:The performance of compiled code

[Anonymous Coward]

Sometimes it's not *your* code, though, and you're in no position to rewrite it using different algorithms.

Re:The performance of compiled code

[mzipay]

if you need something 10 minutes faster, why not start the process 10 minutes sooner?

wow. uh... no.

if you need it ten minutes sooner, then sure, you can start it ten minutes sooner and meet your goal.

if the process takes one hour, then starting it ten minutes sooner does NOT reduce the elapsed time to 50 minutes; it will still take one hour.

Re:The performance of compiled code

[Retric]

Not in 10 hours. 5% faster in 10 hours at the compiler is worth it if you save a few grand in CPU time.

Re:The performance of compiled code

[BlurredWeasel]

I run gentoo (not for performance, but mainly because I am familiar with it, and it is easy), and you know what...I don't bug hunt. And adding -fomitframepointer or whatever the hell the option is (its in my flags somewhere) doesn't cost me anything, makes my system say (made up stat) 5% faster and I am happy. It makes no sense why you should deride me (read: gentooers) as an idiot. We're just end users, and if we can get a little bit of performance for free, well why not.

Re:The performance of compiled code

[exp(pi*sqrt(163))]

And some people waste 50% of their time regurgitating this oft repeated truism to crowds of people who already know it in order to achieve a high karma score from the newbies who think it's profound.

Re:The performance of compiled code

[Derek Pomery]

I see no harm in doing things like omitting frame pointer since typically if I'm actually trying to debug, I'll want to reemerge with debug USE flag (if applicable) and -g anyway.
But, I'm tired of another pointless defense of Gentoo.
Just will say that I've been using it for almost 3 years now after having used Slackware, Redhat and Mandrake for 5 years before that and have can't imagine going back.

Re:The performance of compiled code

[pclminion]

And some people waste 50% of their time regurgitating this oft repeated truism to crowds of people who already know it in order to achieve a high karma score from the newbies who think it's profound.

The newbies get mod points?

Re:The performance of compiled code

[avandesande]

If you spread that 5% over the millions of binaries that are created with a compiler the difference is signficant.
Selecting the right algorithim only effects that one program.

Re:The performance of compiled code

[Anonymous Coward]

So I've spent the 2 hours and made all the algorithms logaritmic; Indeed I've got 500% performance. Now the program takes 10 seconds while before it took 50. So now, let's find the best compiler settings to get that extra 5% and do it in 7.23secs.

But, noooo. Pclminion claims that if I spend another two hours I can get an extra 500%. So I'll bring it down to 2 seconds. And then, I can spend another 2 hours and get another 500% speed up and get it done to 0.4 secs. According to this logic I can optimize everything to run in instant time.

Re:The performance of compiled code

[zCyl]

I think that companies should re-evaluate their "need" for an extra 5% performance.

If you're talking about a program written by one person to be run by one person, or written by five people to be run by five people, or a program that will be run a limited number of times or while people are getting coffee, then absolutely you are correct.

But if you're talking about a small group of programmers making an interactive program (including simulations which people wait for the answer to before starting another run) to be run by millions of people, or to be run iteratively millions of times or over an enormous dataset of comparably size, then 5% is absolutely worth it. If you spend 10 manhours tweaking out 5%, and you've gained only a mere 100 milliseconds, then as a whole you've made out quite well after the collective time saved by those millions of people, or by the millions of runs, are accumulated. And often 5% can result in much more time savings than that.

If you really, positively need an extra 5% performance, you might as well just buy a computer that's 5% faster.

If you can afford all the computers that are 5% faster, then do both! Then you get 10%, and double the benefit. If the first 5% makes a significant difference for a certain application, then the second one probably will as well.

Re:The performance of compiled code

[ivan256]

You're talking about sombody who is considering recompiling the tens of millions of lines of code that make up the operating system and all of the applications he runs, a task that will likely take dozens of hours, to obtain imperceptable performance gains that *may* add up to a few minutes of CPU time gain over the next year..

I think people like this are in another league from what you're describing.

Re:The performance of compiled code

[pclminion]

Sure, you might not need compiler optimizations, but to be bugged with compiler optimizations is just silly...

It's not the optimization that bugs me, it's the Ooohing and Aaahhing that invariably follows even the most basic improvements. As if people are continually surprised that (shocker, here) things get better over time.

Re:The performance of compiled code

[caluml]

Kids running Gentoo delude themselves into thinking that omitting the frame pointer on compiles is going to make a massive difference in terms of performance, and fail to remember it makes bug hunting far more difficult when applications crash.

Gentoo? Crash? No way, dude. It, like, never crashSegmentation fault.

Re:The performance of compiled code

[m50d]

Anyone can tweak compiler settings, and you only have to do it once to get a speed boost for your whole system. It's something worth doing, and can be well over 5%. Yes using the right algorithm is far more important, but it's hard for an end user to wade into the code and check the algorithm, wheras it's easy for me to benchmark compiling with different settings and choose the best.

Re:The performance of compiled code

[Anonymous Coward]

Meanwhile, back in fantasy land...

"Hey boss, the latest build on the cluster is still to slow to meet our production. Mind if I spend a day or two tweaking out the compiler flags to maybe gain a few %?"

"Nope, time is money - here, I'll just push this PR through to buy $50K worth of CPU upgrades - shouldn't take more then a few months. I'll try to work a few weeks of overtime for the support guys to install & test them as well. Of course the cluster will be down for that time, so we may have to make some deals to get time somewhere else ..."

Re:The performance of compiled code

[Anonymous Coward]

Didn't Knuth say

Premature optimization is the root of all evil.

Re:The performance of compiled code

[Anonymous Coward]

Not *the* measurement, but certainly an important one, at least in some circles. 5% improvement would cut a few days off of some of my runs - and that's on a modest size cluster.

Re:The performance of compiled code

[m50d]

Dude, when did you ever see "Segmentation fault" sent over the network? If you're going to use that old joke at least do it r#i*&$£!"^ NO CARRIER

Re:The performance of compiled code

[Anonymous Coward]

Its not uncommon for these to give 100% speedup over GCC.

I've seen 33% with my own eyes, and that's damn good.

I've heard reputable claims of 50%, and that's amazingly impressive.

I've never heard anyone I trust claim a 100% increase from switching from GCC to a better compiler, which makes me suspicious of your claim that it's "not uncommon". Do you have a source for that figure?

Heck, I'd even accept an anecdote if you can describe a convincing scenario. ;)

These other compilers are required if you have codes in Fortran because g77 simply does not cut it.

Now I become very suspicious of your motives in posting - because one of the big features in GCC 4.0, as mentioned in TFA, is that g77 has been replaced with a new Fortran95 compiler called gfortran! Fancy that!

Re:The performance of compiled code

[Anonymous Coward]

And it all depends on the code - on a project I'm working on, g++ somehow beats intel hands down. And I spent a good chunk of time tweaking the build with the Intel compilers trying to make it up to no avail.

Re:The performance of compiled code

[coolGuyZak]

"Its not uncommon for these to give 100% speedup over GCC"

So that's how the KDE developers plan to solve bloat. Sweet.

Note: I use KDE. It was a joke

Re:The performance of compiled code

[killtherat]

I know you're joking, but I've seen that kind of mentality when working with people in high performance computing. It become really important when you have to pay for powering and cooling incredibly large systems. When you start pricing per minute the cost of running a machine compared to the amount of work it can do, sometimes it's more expensive to keep an older machine because you spend more money keeping it on while it takes longer to solve the same problem.

Re:The performance of compiled code

[Q Who]

I find it a blessing that my compiler finds out the best way to inline certain functions for me, that i can just define a function as 'const' when it is const to provide the compiler with information to optimize with, etc etc...

Can you please provide an example where the compiler would take an advantage of const member functions, including compiler version and difference in assembly output, please?

Re:The performance of compiled code

[hackstraw]

Do you have a source for that figure?

My benchmarks are the source, and I have spent most of my time comparing GCC and the Intel compiler.

When I have seen a 100% speedup it was with mostly floating point number crunching. In fact, I have seen a 100% speedup with the Intel compiler for some codes simply changing the optimization flags from -O2 to -O3. I'm not a graphics person, so I don't know about GUI app comparisons between the two compilers. Most other "normal" apps seem to be marginally faster when compiled with the Intel compiler, but nothing as noticeable as with number crunching.

Re:The performance of compiled code

[darkain]

i develop for embedded CPUs. replacing hardware is NOT an option in this market. what you get is what you get. i have spent that extra 10 hours to get that extra 5% speed, and trust me, it was worth every cycle.

Re:The performance of compiled code

[Stween]

That extra 5% is pretty meaningless on modern desktop systems. Let the kiddies play if they want to. If I can see an up to date KDE running pretty nicely without turning settings down on a 450MHz P3, then they can waste all the time they like compiling the same KDE for their 3GHz beast of a P4.

The 5% can come in useful on smaller platforms though. Now that we're seeing mobile phones on the market that people can code for, it's no longer dedicated embedded systems where every cycle matters. There are situations where those extra cycles are needed, and to this day for some embedded platforms and/or network processor systems, taking the assembly output of the compiler and hand optimising that instead is still required.

You're correct so long as you're implying that most people shouldn't really need to tweak for those few % that they'll never notice, as I suspect you are. Bear in mind the compiler is not the be-all and end-all though, there are situations where you really need to watch what it's doing to make sure you're not wasting power.

Re:The performance of compiled code

[kfg]

Which saves you the most time, getting the right answer in 10 days, or the wrong one in 9 1/2?

I am not arguing against the value of execution speed.

KFG

Re:The performance of compiled code

[Anonymous Coward]

You realize that alot of people use a computer to do more then just run their OS & desktop right?

Re:The performance of compiled code

[GeoGreg]

Believe it or not, there are commercial applications run every day that take weeks to complete one run. In particular, I'm thinking of the seismic imaging programs run by oil exploration companies. Given that a single offshore oil well can cost tens of millions of dollars, they are willing to throw both hardware and programmer time at the problem. If you can squeeze in one more iteration to refine the image before making a decision, it can be worth millions. So yeah, there are cases where algorithm choice, compiler efficiency, and fast hardware all work together.

Re:The performance of compiled code

[Anonymous Coward]

Dude what's the exact station in the pic in your sig? I live in Moscow and I don't remember seeing such a nice station.

Re:The performance of compiled code

[Stween]

You realize that alot of people use a computer to do more then just run their OS & desktop right?

Yes. You'll notice that I said "most people shouldn't really need to tweak for those few %". Emphasis added for your comprehension.

Re:The performance of compiled code

[exp(pi*sqrt(163))]

Well, newbies to modding do.

Re:The performance of compiled code

[Cobron]

This is ridiculous, you are comparing end users with the programmers.

Re:The performance of compiled code

[damiena]

AYNARD: It reads, 'Here may be found the last words of Joseph of
Aramathea. He who is valiant and pure of spirit may find the
Holy Grail in the Castle of Segmentation Fault'.
ARTHUR: What?
MAYNARD: '... the Castle of Segmentation Fault'.
BEDEVERE: What is that?
MAYNARD: He must have crashed while carving it.
LAUNCELOT: Oh, come on!
MAYNARD: Well, that's what it says.
ARTHUR: Look, if he was crashing, he wouldn't bother to send it over the network
'aaggggh'. He'd just print it!
MAYNARD: Well, that's what's his comment says
GALAHAD: Perhaps he was dictating.

Re:The performance of compiled code

[dodobh]

Code quality? No. Program quality? Yes!

If your code is used by a million people whose time is worth a dollar an hour, saving them each an hour of runtime is equivalent to saving a million dollars during the lifetime of the program. Compared to that, programmer time is *cheap*. Even if you bill at 200 USD/hour, and spend 20 hours on it.

Re:The performance of compiled code

[Surt]

Unless of course you're concerned with the performance of the application on someone else's computer. Like if you, for example, release your binaries.

Re:The performance of compiled code

[pclminion]

This is ridiculous, you are comparing end users with the programmers.

What do end users and compilers have to do with each other?

Re:The performance of compiled code

[kfg]

Program quality? Yes!

Exactly my point.

. . .saving them each an hour. . .

For which runtime is not the only issue.

KFG

Re:The performance of compiled code

[Brandybuck]

If you have a choice of algorithms, then of course use the better algorithm. But for most of the day-to-day code we deal with, we don't have that choice, because we're not dealing with code that has any grand algorithms to it. For example, if I'm writing a GUI frontend to a command line app, what are my choices of algorithms? Not much.

In my real life coding work, the places where algorithm efficiency makes a difference are far outweighed by those places that don't. And of those places that do make a difference, the performance is rarely a critical need. For example, I just coded up some RAMDAC lookup tables, and a difference of algorithm would make a huge difference in efficiency. But this particular routine was triggered by a user event (clicking a button in a config dialog), so that my dogslow but highly readable/understandable algorithm wasn't a bottleneck for anything. In this case tweaking the compiler settings would have given a 5% boost to everything, but a change in algorithm would only have given a 1/10 second boost for an event that would happen approximately once a week or less.

Re:The performance of compiled code

[mattgreen]

The amusing thing is that people are actually annoyed when I point out that omitting the frame pointer is a micro-optimization that provides minimal gain.

All hail the placebo effect.

Re:The performance of compiled code

[Anonymous Coward]

But it does something and that makes us happy. It's not like we're spending any significant time making this change. You're being an asshole.

Re:The performance of compiled code

[Anonymous Coward]

"It's not like we're spending any significant time making this change"

Hah! You've never installed Gentoo have you?

Re:The performance of compiled code

[Anonymous Coward]

It's very rare that I have to have a piece of code run by a certian time.

It's ussually the case that I'm burning the clock waiting for the run to complete. It's elapsed time that's the killer, and starting 10 minutes earlier isn't going to help that.

Re:The performance of compiled code

[mav[LAG]]

A question here: I'm not being rude or anything but have you ever done any assembly programming? It's just for an informal survey I'm doing.

Attention mods. This is a genuine question directed at user 701203 - mattgreen. No sarcasm or trollishness or any kind of flamebait is implied or should be inferred.

Re:The performance of compiled code

[Anonymous Coward]

Typical embedded platforms are constrained for space, not speed. Most optimizations increase the size of your binary.

Replacing CPU's most certainly IS an option if you're the one making the embedded equipment. You don't try to squeeze more power out of your old platform when it already does what it's supposed to do, you work on the next product up in the lifecycle. Those who need it will buy it. It's not planned obsolescence, since your old product continues to work just fine.

Re:The performance of compiled code

[fitten]

It's a placebo. There's nothing wrong with something 'making you happy' but you have to remember it's a placebo. Using this optimization and then crowing about it, for example, is just silly. Be happy all you want but don't think (and claim) that it's more "real" than it is.

Re:The performance of compiled code

[bit01]

And in both groups you will find people who believe that execution speed is the measurement of code quality.

It's been my experience that execution speed is a very good indication of code quality.

Decent code performance is actually not that hard and programmers who fail that simple test are likely to be poor overall. In particular, algorithm selection has a dramatic effect on code performance and programmers who aren't even capable of choosing the right algorithm, usually a 5 minutes of planning task, are going to do everything wrong.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Re:The performance of compiled code

[drew]

We're just end users, and if we can get a little bit of performance for free, well why not.

i wouldn't exactly call it free when you spend more time recompiling all of your applications than you could ever save running them. i'm not saying this to troll, i've been using the ports system on freebsd since before gentoo existed. if you're using gentoo because you are familiar with it, and like the way it works, great. i just can't help but be amused by gentoo users that talk about the performance improvements they get from spending half the time they are using their computer compiling things.

Re:The performance of compiled code

[Dominic_Mazzoni]

This has always bugged me.

Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.

Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.

I totally agree. There is an interesting exception, though: sometimes I've seen people write a very complicated algorithm in a high-level language (Perl, Python, Matlab, etc.) that has great theoretical runtime, but huge overhead. I write the same thing in straight C using the naive algorithm and it ends up being 10x faster in practice, with 1/10 as many lines of code. So it does go both ways.

Re:The performance of compiled code

[sl3xd]

I agree completely with the arguments against using Gentoo for performance reasons.

It certainly isn't why I run Gentoo.

I run it because I like the way it works. I've recently taken a look at some of the other distros (SuSE, Fedora, ... I still run debian on a fileserver, though). Distros like SuSE, and Fedora (even when using things like APT-RPM, yum, etc.) drove me nuts. There were dependancies that were *completely* unnecessary being installed. And the 'RPM Hell'; drove me INSANE. Debian is a serious step up from SuSE and Fedora in that respect, but Gentoo puts Debian to shame.

And I can honestly say -- I don't see where people have fits about having to compile everything. After the initial install, you can have any updates compiling at a well-niced priority. Unless I'm trying to play a CPU-intensive game (like Doom3, UT2004, etc.), I never even notice a performance difference. (I will admit this: my development work is done completely over SSH to another box, so emerging isn't slowing my 'real' compile jobs).

Even stranger is that most of the time, things don't even take long to compile. Huge apps/groups of apps like KDE, OpenOffice, and to a lesser extent, GNOME are an exception. And for those, I start the build when I leave work for the day, and it's done when I come back.

I don't use Gentoo for performance reasons. I use it because I hate the dependancy hell involved with pre-compiled binaries. I don't have to deal with it when using Gentoo; it's that simple.

And people whining about compile times -- seriously... unless you want to play Doom 3 while compiling KDE-- you've got issues, because compiling the apps isn't an issue at all.

Re:The performance of compiled code

[mattgreen]

Yup, but not a ton. Where do I score on the survey?

Re:The performance of compiled code

[mattgreen]

Exactly. You couldn't distinguish an app compiled with frame pointers disabled from one with frame pointers enabled. The reason I point this particular optimization out is that it makes life hell for developers if you end up sending a core dump file in. This is a net loss in my book, since open source software evolves rapidly and being able to assist in reporting bugs is vital.

How is pointing out that one optimization people crow about is largely ineffective being an asshole?

Re:The performance of compiled code

[Jeremi]

It is profound -- to the newbies. Not everyone is as knowledgable as you are.

Re:The performance of compiled code

[hankaholic]

This has always bugged me.

Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.

Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.

While there's a lot of truth to the idea that some algorithms scale much better than others, there's also the fact that modern CPU architectures require *tons* of bit twiddling to ensure optimal performance, and that's something that a good compiler can do fairly well. Algorithmic choice can mean large differences in runtime; however, a good compiler could realistically improve an inner loop's runtime several times over simply by choosing the best execution path.

Wasting time over 5% is often just that -- wasting time. However, a good compiler should allow an algorithm to use the hardware to its fullest whenever possible.

People will dump tons of time into microoptimization and trying to guess which compiler options will do the best things with a given piece of code. What I don't see is why a firm interested in high-performance code wouldn't invest resources into optimizing the compiler's output... it seems to me that the cost vs. benefit is much more attractive to spend that time actually improving the compiler rather than writing the oft-cited genetic algorithms for choosing a good set of compiler flags and hoping somehow to get amazing results by hitting upon some magic combination.

Spend time tailoring the code to the compiler, and you've fixed the code, once. Teach the compiler to do the right thing, and all of your code will benefit.

Shortsighted bastards, all of them.

Re:The performance of compiled code

[Anonymous Coward]

> well why not.

Because we, unlike you, have a life.

Re:The performance of compiled code

[Anonymous Coward]

By niceing the compile and changing the flags of one file it can run without any notice, recompiling EVERY program on your computer. It's not hard to do this stuff if this is how you were brought up rather than a clicky OS. It's like being angry at rich kids; they can't help they were born into it. It's what they have. For the same reason, I can't help I am American, it's where I was born and my 50 or so first cousins, uncles, aunts, and grandparents live here. It's not as easy to say it is a conscious choice. I use gentoo because it's what I am comfortable with and works for me.

Re:The performance of compiled code

[register_ax]

I've done some too (coding in assembly) and also use Gentoo. I agree with the points being addressed by user 701203.

I have windows running on vmware too because I live in the Real World. I will prefer to use linux, but what are you going to do?

Re:The performance of compiled code

[Dr. Weird]

I think that companies should re-evaluate their "need" for an extra 5% performance. Here's an idea -- if you need something 10 minutes faster, why not start the process 10 minutes sooner?

Is this a troll? In most high-performance computing environments (national and local supercomputing centers) -- at least when they are being well-utilized -- they are in non-stop use. You don't start ten minutes sooner because you or another user are hammering the machine with other jobs.

Re:The performance of compiled code

[tokabola]

I can't believe I'm giving up being able to mod this thread, but here goes.

I have installed Gentoo, and typing -fomitframepointers took less than four seconds. The time it has saved me since may not be much, but it's a lot more than four seconds.

Tommy
NAPT (Not A Professional Typer)

Re:The performance of compiled code

[chthon]

Yes. I have done some pretty COBOL coding and maintenance, and I was able to create simpler algorithms to do things faster than previous programmers who thought they were smart.

I always tried to find a mathematical underground, implement that in the simplest way and was able to get dramatic speedups, without even intentionally tweaking code for performance.

Re:The performance of compiled code

[mav[LAG]]

No score, it's not that kind of survey. I'm trying to determine if there's any correlation between the optimising-obsessed (especially using compiler switches) and whether they've done any assembly before.

To declare my position: I am optimising obsessed (since it's fun and makes me money in some situtations) but not via -O switches. I was _very_ surprised to find -O3 and -fomit-frame-pointer sped up the CVS version of FlightGear by somewhere around 40% last night, since I am in the better algorithm and pure assembly for tight loops camp.

Re:The performance of compiled code

[10Ghz]

i wouldn't exactly call it free when you spend more time recompiling all of your applications than you could ever save running them.

Well, yes and no. Yes, compiling can take long time. But so what? I mean, when the machine compiles, I can do someting else. I can keep on using the computer, or I could go out for lunch for example.

If I enabled some optimizations that made the machine 5% faster, started the recompile in 9pm, went to bed, and checked the results in 6pm in the next evening (when I get back home from work), how much time would I have wasted doing that compile? None. When the machine was compiling, I wouldn't have been using it in the first place (I was either sleeping or at work). You are not required to sit in front of the computer and watch it compile. You are perfectly free to do something else instead.

You could say that it gives you best of both worlds. That extra 5% might not be much, but it can make the system a bit more snappy. And that matters when you are actually using the machine. Yes, it might take hours for it to recompile the system, but since I can watch a movie, sleep, read a book while it does so, I don't really see myself as wasting time. If anything, we SHOULD step away from the computer once in a while.

And, if I really need to, I CAN use the computer while it compiles.

FWIW: I use Gentoo, but I'm not performance-junkie. I have modest optimization-settings, and performance is not the main reason why I use Gentoo. But if I can get some extra performance, so much the better!

Re:The performance of compiled code

[UnknownSoldier]

> I frequent a game programming board, and the widespread use of C++ has led to an abundance of nano-optimization threads, the most amusing of which was an attempt to optimize strlen().

Which board was this?

Re:The performance of compiled code

[4of12]

the places where algorithm efficiency makes a difference are far outweighed by those places that don't.

Amen.

Most places achieve increased efficiency through maintainable code that is easy for programmers to read, understand and fix.

I'd all love to drive a Ferrari to work every day, but I'm not prepared to put in what it takes to learn how to work on them.

A good friend wrote a very efficient routine for specialized matrix solves that we all loved to use because it was 40% faster than anything else available. But his code was obtuse, hard to understand. As a result, if we found any problems with it, we would go to him for the fix rather than confront that tight block of code. In the longer run, as he went on to other jobs, there was less willingness to use something that - when it ever broke - cost too much to fix in terms of peering at code and figuring out WTF he was doing.

Re:The performance of compiled code

[Anonymous Coward]

Neo (Keanu Reeves) spend 12 hours tweaking ALL and get an extra 530% performance!!!

1 * (1.00 + 5.00) * (1.00 + 0.05) = 1 * (1.00 + 5.30)

Re:The performance of compiled code

[losinggeneration]

Where do you get 10 minutes from 5% performance? Just curious because it's close to 5am and my quick math without much thought (a paradox in itself) is giving me something different.

intel compiler

[Anonymous Coward]

wasn't one of the goals of 4.0 to become more like intel's prized x86 compiler?

Re:intel compiler

[MORB]

Intel compiler's reason why it generate faster code is because it does auto-vectorisation (ie, it automatically finds out how to transform some code patterns to take advantage of native vector operation, such as those provided by sse). They started to implement this in gcc 4.0, but it's a veyr first iteration that for what I know is still kinda limited. I'm not even sure it's enabled by default, even in -O3. There are lots of improvement there targeted at gcc4.1.

Re:intel compiler

[X]

Actually, even if you completely turn off auto-vectorization, or compile on IA64 where such concepts are effectively meaningless, the Intel compiler still performs very well.

I wish people would stop talking about autovectorization like it's an instant "code runs faster" thing. Yes, in some cases it makes a huge difference. In many others, it doesn't even apply.

Re:intel compiler

[Kupek]

Auto-vectorization is not the reason why Intel's compiler is better. It certainly helps, but in my experience, not much. Intel's compiler just does better optimizations across the board. Which is no surprise: Intel is making a compiler for thier chipsets. They have inside knowledge of what's best to do when for a particular chip. Further, Intel's compiler is marketed as the fastest compiler for x86, which as far as I know, is true. Hence, they spend a lot of time on the optimizations.

GCC, on the other hand, has a different goal: get a working compiler on as many platforms as possible.

Re:intel compiler

[ultranova]

I wish people would stop talking about autovectorization like it's an instant "code runs faster" thing.

Um, if it doesn't make code run faster, what's the point of including it ?

Re:intel compiler

[X]

Um, if it doesn't make code run faster, what's the point of including it?

Sigh.. I wasn't saying that it doesn't make code run faster. I was saying that it doesn't necessasrily make code run faster. Auto-vectorization is only a win in certain circumstances. There are a whole host of optimizations that only apply in specific circumstances and/or only improve performance in certain circumstances and slow things down in others. If there weren't trade-offs with optimizations, compilers would just have "-O" and wouldn't bother with tons of other optimization flags.

I got your value

[Anonymous Coward]

"Like a baby, we won't really appreciate its value until it's matured a bit."

Does this mean I have to wait until it's 18?

Re:I got your value

[Martin Blank]

Generally yes, although you'll only have to wait until 16 in some states.

Re:I got your value

[Ruud Althuizen]

Here in the Netherlands you only have to wait until it's 12, with the permission of the parents. And I don't think the devvers will have a problem with it.

Re:I got your value

[lilmouse]

No, we have to wait until Micr^H^H^H^Hthe dev team puts out a bunch of patches for it ;-)

OTOH, if I want better performance *now*, I could hack on the code myself. Wait a sec, if I want better performance, I shouldn't touch the code...

--LWM

Re:I got your value

[k98sven]

Does this mean I have to wait until it's 18?

Not much of a wait. Release announcement, March 22 1987.

Seems GCC reached 'maturity' over a month ago.

Re:I got your value

[Anonymous Coward]

No, just tie it down, tape up its mouth, and threaten to kill it if it ever tells anyone. Then go to town!

Re:I got your value

[Anonymous Coward]

Unless you're only about 2-3 years older than the thing, in which case any time goes.

Re:I got your value

[Justin205]

Lucky Canadians only have to wait until 14.

Incentive to move?

Re:I got your value

[Anonymous Coward]

No. By the time it turns 18 (and is ready to begin working in prostitution), it should have already been serving you for about 10 years, working on your farm.

The tricky bit is around 23, when it's no longer profitable as a prostitute. You have to bring it back to farming. Then you get a few more years out of it, before the HIV it picked up earlier, takes its toll.

(Of course, I use "farming" generically. You can also have your kid sewing garments for sale in America, etc.)

email

[Anonymous Coward]

I tried to email you about your "thethere" mistake, but you don't want to talk to people apparently. Not the most important of corrections maybe, but anyway...

scott.ladd@coyotegulch.com
SMTP error from remote mailer after RCPT TO::
host smtp.secureserver.net [64.202.166.12]:
553 217.209.223.* mail rejected due to excessive spam

Fast KDE compile.

[Anonymous Coward]

It's damn fast for KDE compile as someone tested.

Re:Fast KDE compile.

[badfish99]

Well, the article you link to starts with the words:

KDE sources now blacklist gcc 4.0.0 because it miscompiles KDE

It must be easy to compile fast if you don't mind getting the wrong answer.

Re:Fast KDE compile.

[Anonymous Coward]

It miscompiles KDE for what architecture, with what CFLAGS, what optimization, what system ?

It has been blacklisted because some core KHTML components failed.

But all in all the compiled KDE 4.0.0 that I am using works perfectly but otoh I compiled it with these flags:

-O0 --Wl,--as-needed -pipe -g

Re:Fast KDE compile.

[Anonymous Coward]

KDE 4.0.0

I want a time machine too!!

Re:Fast KDE compile.

[Anonymous Coward]

... erm quite obvious a typing mistake :) KDE and GCC both 3 letters :)

Re:Fast KDE compile.

[Anonymous Coward]

Just out of interest, when is KDE 4 scheduled for release? I've tried googling, but all I get is a bunch of hopelessly out of date links (e.g. suggesting December 2004, etc). What's the most recent estimate, straight from the horses mouth, if possible?

Re:Fast KDE compile.

[Anonymous Coward]

At least a year away, probably more. The porting of the base libraries to Qt4 will start after the long awaited switch from cvs to svn is done, then it will be a kde 3.5 "usability and application" release, then kde 4.

Re:Fast KDE compile.

[molnarcs]

Can someone give us a link to an explanation of why it was blacklisted? What specific problems they had with it?

Re:Fast KDE compile.

[Anonymous Coward]

it compiles, but sometimes the code it generates gives unexpected results (AFAIK only for khtml, the other stuff works well)

Re:Fast KDE compile.

[AArmadillo]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
GCC bug report
http://lists.kde.org/?l=kde-cvs&m=111451142117674& w=2
KDE CVS report

It involves some problem with register allocation. It seems only to miscompile KHTML, and there is already a patch attached to the GCC bug report (although the patch just disables the optimization that is causing the problem, rather than fixing the core problem itself).

Re:Fast KDE compile.

[northcat]

Come on, the guy who posted the slashdot story is an "amateur" who doesn't really know how to "test" gcc. But I know what's going to happen. More "technology experts" like him are going to post "reviews" on their blogs, slashdot and other "technology" sites and within a few weeks, there will be a general opinion on the 'net that GCC 4.0 sucks. Especially since a lot of people seem to hate GNU so much.

Re:Fast KDE compile.

[Anonymous Coward]

Well considering it is uninitialized data who care, the optimization is not really an optimization but more accurate information for global allocation.

Re:Fast KDE compile.

[Anonymous Coward]

For those of you who miss the humor in Andrew Pinski's reply, some background:

GCC's optimization passes try to be as machine independant as possible. They, of course, handle machine specific things, like allocating and spilling registers and so on. But sometimes some platforms have some stupid rules for what registers and instructions to be used when (instruction XXX sets a flag, so instruction YYY has to be issued afterward to use that flag before it gets overwritten, or maybe register foo had been spilled so it has to be reloaded before ZZZ, or this value always has to be in register A, etc). A lot of this code ends up in a function called reload, in a file by the same name.

Over the years reload has grown, and grown, and grown. No developer understands all of it. A goal of many people is to improve the register allocator and othr passes to make it so reload can be disabled on most platforms. The thing is, well, not quite buggy, but fragile and causes many bugs when things change.

So when Pinski says "Reload, wow, not that unexcepted really." he means it. There are also other comments in that thread, like "Though it is still a reload patch, and all reload patches are dangerous."

From what I understand from the rest of the thread, reload needs to make two hardware registers the same for an instruction, but ends up using up a virtual register it shouldn't, which later confuses the rest of the compiler since there are still notes to not use the virtual register.

The bug has been fixed in CVS. Patch is in the attached web page, both for khtml to use with 4.0.0 and for GCC if you roll your own and want to compile khtml.

Re:Fast KDE compile.

[drew]

someobdy's making that up. nothing compiles kde quickly.

Re:Fast KDE compile.

[Per Abrahamsen]

It is a GCC bug, and it has already been fixed on mainline. The KDE people are going to love 4.0.1 :-)

The Future?

[liam193]

Version 4.0.0 is laying a foundation for the future, and should be seen as a technological step forward with new internal architectures and the addition of Fortran 95.

While I know the benefits of Fortran 95 are a big thing, saying it's a technological step forward to incorporate for the first time a 10 year old standard seems a bit ridiculous. When I first saw this article I had to check my calendar to make sure it was May 1st and not April 1st.

Re:The Future?

[discordja]

I can see how that'd throw you off since it's May 2. :)

Re:The Future?

[Anonymous Coward]

Considering the glacial pace of change in the Fortran world, using a "standard" created as recently as 1995 is considered to be a radical and reckless act.

Re:The Future?

[Lemming Mark]

It's not just the addition of F95, which obviously only benefits Fortran users.

GCC4 has a new optimisation architecture called "Tree SSA". This introduces a new representation (well, actually two: GENERIC and GIMPLE, although the latter is a subset if the former) for programs under compilation. The GIMPLE representation is used for advanced high-level optimisations before feeding the code into the compiler "back end" for architecture-specific optimisation and code generation.

The advantages of Tree SSA are multiple:
* cleaner architecture
* allows high level optimisations that were previously hard or impossible to do at the RTL (Register Transfer Language) level used by the backends
* despite being "high level" many optimisations that take advantage of program structure can be made language independent because of the GENERIC / GIMPLE representation

However, it'll take a while for new optimisations that have been enabled by this framework to be written. The idea is that Tree SSA breaks a fundamental barrier to the continued improvement of optimisation in GCC and should yield gains in years to come.

There are some other nifty things in GCC4 like the "mudflap" system for detecting program errors. Enhanced type-checking fussiness is also welcome as far as I'm concerned, even if it results in some compile errors.

Re:The Future?

[TeknoHog]

While I know the benefits of Fortran 95 are a big thing, saying it's a technological step forward to incorporate for the first time a 10 year old standard seems a bit ridiculous.

C and C++ are even older than F95. Why should anyone write a new C/C++ compiler these days?? Well, obviously because there's so much code around that could use a better compiler.

To me it seems natural to include F95 in GCC 4 because of the parallelization improvements. It's part of the bigger picture of technological improvements in GCC. Also keep in mind that today's bleeding edge computer science will take years to percolate into mainstream IT. I bet the first F95 compilers weren't as efficient as GCC 4.

Re:The Future?

[Anonymous Coward]

The last C standard was finalized in 1999 (that's what C99 means). The last (and only) C++ standard is from 1998. There was a recent technical revision to C++, came out this year or last.

SH

Re:The Future?

[Anonymous Coward]

The real reason for the new Fortran compiler is this:
nobody wantted to update the old G77 compiler and it would take a long time to do. Now gfortran is a nice fortran compiler with issues to resolve. Now gfortran is also becoming a fortran 2003 compiler too so now GCC is up todate with FORTRAN.

Re:The Future?

[m50d]

How long did it take for proper f77 support? Code standards take ages to be implemented properly, they're nowhere near support for the latest C yet.

Re:The Future?

[Anonymous Coward]

c
c.... Put on f77 jedi master cloak
c

Look not to the new ways, for that is the surest path to the dark side. A true F77 master has no need for such things, and fears not the crufty and abominable use of malloc and goto. Remember, the greatest wisdom in the use of F77 is

"Do or do not, there is no while"

c
c.... Take of F77 jedi master cloak
c

Re:The Future?

[GauteL]

It IS a big thing. This is the first freely distributable, readily available compiler of Fortran 95.

Up until now, my PhD work has needed compilers I can't just simply install without high fees, because the academic free license for propriatary compilers still sounds a bit fishy in it's requirements. This is actually a major boost for the Scientific Computing community.

However, lots of people have just NOW started to trust current F95 compilers (lots of academic code are still written in F77). It will be several more years until they trust the GNU Fortran 95 compilers.

Besides, while it is called Fortran 95, does not mean it was actually in heavy use by 1995.

We have this thing on Earth, called tact.

[Tim Browse]

Like a baby, we won't really appreciate its value until it's matured a bit.

Is that what you say to new parents? :-)

Re:We have this thing on Earth, called tact.

[t_allardyce]

Yeah, just before they find out about shitting, puking and waking up at 3am.

Re:We have this thing on Earth, called tact.

[Narchie Troll]

No, you say:

"What the FUCK were you THINKING? You turn around and take that thing right back to where you found it."

Re:We have this thing on Earth, called tact.

[Anonymous Coward]

Or the worst, waking up shitting and puking at 3am...

Screenshots?

[jmcneill]

Where are the screenshots?

Re:Screenshots?

[wawannem]

Here you go: bash$ gcc -o test main.c bash$ As you can see, the new version of GCC clearly has some hurdles to jump before being production ready.

Re:Screenshots?

[wawannem]

damn... I meant:

Here you go:

bash$ gcc -o test main.c
bash$

Re:Screenshots?

[stuuf]

Screenshots of what? error messages?

Re:Screenshots?

[Anonymous Coward]

One of my small joys in life is reading slashdot and seeing people who just didn't get the joke. :)
-K

Re:Screenshots?

[youknowmewell]

I don't care about screenshots, I just wanna know if it runs linux.

Re:Screenshots?

[dizzy tunez]

Okay, here it goes.

$ gcc

Re:Screenshots?

[Anonymous Coward]

You must have learned to use gcc from a comment at the top of some phpnuke exploit. Any Real Hacker(tm) would have written that as

gcc main.c

Re:Screenshots?

[Anonymous Coward]

you're a douche.

seriously. a douche.

Re:Screenshots?

[Anonymous Coward]

Why's that?

Compilation Speed Test by a KDE developer

[Anonymous Coward]

http://www.kdedevelopers.org/node/view/1004

Qt:
-O0 -O2
gcc 3.3.5 23m40 31m38
gcc 3.4.3 22m47 28m45
gcc 4.0.0 13m16 19m23

KDElibs (with --enable-final)
-O0 -O2
gcc 3.3.5 14m44 27m28
gcc 3.4.3 14m49 27m03
gcc 4.0.0 9m54 23m30

KDElibs (without --enable-final)
-O0
gcc 3.3.5 32m56
gcc 3.4.3 32m49
gcc 4.0.0 15m15

I think KDE and Gentoo people will like GCC 4.0 ;)

Re:Compilation Speed Test by a KDE developer

[taniwha]

except that some stuff doesn't quite compile correctly yet ... hold off on building KDE with it for a while

Re:Compilation Speed Test by a KDE developer

[halivar]

gcc 3.3.5 23m40

You mean 23 months and 40 days, right?

Re:Compilation Speed Test by a KDE developer

[Anonymous Coward]

he mean gcc 3.3.5 have 23 years old, is a male and is from a city named '40'

Re:Compilation Speed Test by a KDE developer

[Dark Coder]

Compile time, a comprehensive test does not make.

Actual execution rate, doth make.

Power is different.

[Anonymous Coward]

You've got to benchmark each platform separately. Sure, they share some higher level optimizations, but the type of processor determines a lot of important stuff (like instruction scheduling) and is dominant.

Question to the maker of Acovea

[Anonymous Coward]

What happened to the -ftracer option? Is is still generally useful for optimization in GCC 3.4 (and later)? Or has it now become part of one of the -O options?

Re:Question to the maker of Acovea

[Anonymous Coward]

As having just run an Acovea bench last weekend with GCC 3.4.3, it definitely suggested -ftracer above and beyond -O3, so I'm guessing its not part of an -O yet.

What about windows?

[Spy der Mann]

One of the problems with MINGW32 is that the linker doesn't respect the --gc-sections. When I read about the improved dead code ellimination (in the what's new of GCC 4.0), i wonder if we windows users could *finally* deliver executables as small as those made with the VC++ compiler.

Any info on this? When's the mingw port going to be done? Has anyone tested the unofficial mingw build (forgot the url, sorry)?

Re:What about windows?

[Aaron W. LaFramboise]

Yes, GCC 4.0 builds under Windows. See http://gcc.gnu.org/gcc-4.0/buildstat.html, and the mingw-users mailing list. I don't think that --gc-sections is nearly as useful as some people seem to think it is. Even on ELF, the only target that supports it, its only supported when doing static linking (which obviously is not a binary size improvement over dynamic linking). Also, the -ffunction-sections option for GCC commonly used with this linker switch can inhibit optimizations. Even when -gc-sections can be used for an improvement, for much C code, it tends not to actually remove very much. The linker already has machinery to merge various sorts of the worst executable bloat, such as duplicate template instantiations. This switch is most useful for various pathological cases that most people, as near as I can tell, don't experience. If an executable is hugely bigger than it needs to be, your best bet is to examine the executable with objdump to determine exactly what is using up all of this space. Oftentimes its fairly easy to strip out extra unneeded fat. Aaron W. LaFramboise

Re:What about windows?

[Ian Lance Taylor]

The linker --gc-sections option eliminates unused sections between object files. The compiler only generates one object file at a time. So they are different issues.

That said, see the -combine option, which permits compiling several source files together, permitting better inlining across source units.

If executable size is your main concern, make sure you compile with -Os. The default set of optimizations tend to try to decrease execution time by increasing code size (this is only a generalization, of course, as you also increase execution time by keeping your code small enough to fit in the L1 cache). -Os tells the compiler to prefer to decrease code size.

fpmath=sse

[Chemisor]

Where would I find on which architectures fpmath is set to sse by default? The info file doesn't seem to have that information. And is it possible to tell the compiler to always use SSE instead of the FP registers, so I wouldn't have to have so many emms's all over the code? (In generic MMX-using routines which don't usually know what'll happen after them)

Re:fpmath=sse

[Anonymous Coward]

It's the default setting for x86-64 architecture. However, I tried it on an Athlon XP, and wasn't really impressed by the results, on my project it was significantly slower than 387. So it might be sensible to try both settings on a x86-64 too.

Re:fpmath=sse

[Anonymous Coward]

Be careful though. If you want to use sse only make sure to supply --fsingle-precission-floats. Otherwise something terrible happens: If you write

float x, y, z;
x=y*13.2*z;

gcc will take 13.2 for a double, it will do half of the expression with sse and the other half with FP.
That is in fact worse.

I wish gcc had an option
--fbest-code-for-current-machine

where it will enable all the options to get the fastest code for the machine it is executing in. So no deps on the incompetent autoconf scripts, etc. Compiler detects CPU and turns on apropriate options.

kettle? black?

[dem3tre]

I love the open source movement but I wonder why the following comment is OK for open source projects and not close source?

quote "That said, no one should expect a "point-oh-point-oh" release to deliver the full potential of a product, particularly when it comes to a software system with the complexity of GCC."

I bet no one would dare say that about certain product from Redmond.

Re:kettle? black?

[Dan Berlin]

Significant difference. If you ask gcc folk (like me), we'd happily tell you that 4.0 will probably be, performance wise, win in some cases, and a lose in others. Anytime you add large numbers of optimizations, it takes a while to tune everything else so that we get good generated code. 4.0 is more a test of the new optimizers than something that is supposed to produce spectacular results in all cases.

Re:kettle? black?

[Spy der Mann]

He did NOT say "fix bugs". He said "deliver the full potential", i.e. "developing over the new features".

Re:kettle? black?

[cbrocious]

MS doesn't use the "release early, release often" methodology.

Re:kettle? black?

[canadiangoose]

If the point releases from Redmond were free upgrades, then it might not matter so much. Last I checked, upgrading from Windows NT 5.0 to 5.1 costed several hundred dollars.

Re:kettle? black?

[k98sven]

quote "That said, no one should expect a "point-oh-point-oh" release to deliver the full potential of a product, particularly when it comes to a software system with the complexity of GCC."

I bet no one would dare say that about certain product from Redmond.

I don't know about that.. But first off GCC (and other free software projects) tend to be much more upfront about the fact that radical changes also means new bugs. Slashdot types (read: engineers) tend to value that kind of technical honesty over marketspeak.

Secondly.. when did Microsoft last develop something radically new? Most of their products are over a decade old, and a lot of those which aren't are based on technology they bought up from competitors.

Thirdly, unlike Microsoft, the GCC guys aren't doing everything in their power to get me to upgrade.

Re:kettle? black?

[superpulpsicle]

Boy that sounds like we should stay away from GCC 4.0 until at least 4.1 and beyond.

Re:kettle? black?

[Anonymous Coward]

Secondly.. when did Microsoft last develop something radically new?

Does .NET Count?

Re:kettle? black?

[imroy]

I think you're a little mixed up there. When we criticize MS, we're often referring to the release of known buggy and badly implementated software to the general public. Instead the submitter of this article is referring to the "full potential" of the new optimization framework in GCC-4.0. It will, in theory, allow for much better optimizations to be performed on internal parse tree. But for now many of the CPU models are incomplete or non-existant, or something like that. The full potential of these optimizations will be delivered in a later release, either 4.0.x or 4.1, or perhaps a little of both. And the GCC team wouldn't have released GCC 4.0 with known, serious bugs.

Or perhaps I've just been trolled. Wouldn't be the first time. I see that this is your first comment on slashdot. Welcome. Just don't troll.

Re:kettle? black?

[abradsn]

This is also why MS Products are dependable.

Re:kettle? black?

[Anonymous Coward]

Does .NET Count?

I doubt it.

Re:kettle? black?

[Anonymous Coward]

The other argument that has been missed being... GCC is not charging you money to upgrade/use 4.0. When you pay a bunch of money, expectations of performance, reliability, and speedy bug-fixes rise. When office 2020 is released for example for $10,000 and we have no idea if/when 2020.1 will be out to fix any bugs reported after release (cuz we know testing doesn't catch them all) so who wants to pay that much?

Re:kettle? black?

[Miniluv]

No, what it means is that if you're doing anything that is compiler sensitive, you should test before you deploy. Some people are seeing gains with GCC4, other people are seeing the same, and some are seeing losses. Each group needs to make a decision about a compiler for their situation.

The GCC folks released this with it being well documented that it wasn't going to blow the doors off for everyone in every situation, but instead that this was a major step forward for internals, which should allow them to make some major steps forward that are externally visible soon.

Re:kettle? black?

[StormReaver]

"...I wonder why the following comment is OK for open source projects and not close source?"

Here are the top two reasons:

1) Any motivated programmer can fix the Free Software problems, while we're stuck with what the closed source shops provide.

2) Free software is also gratis, while the closed source programs are expensive (usually outrageously expensive). If a company is going to charge an enormous fee, the product had better be damn near perfect (which it isn't).

When the product is gratis+libre, the developers deserve a pat on the back and a lot of leeway.

Re:kettle? black?

[Grishnakh]

The other argument that has been missed being... GCC is not charging you money to upgrade/use 4.0. When you pay a bunch of money, expectations of performance, reliability, and speedy bug-fixes rise.

Exactly. The goals in releasing software are completely different for GCC and MS.

For GCC, like a lot of open-source products, the idea behind releasing all-new x.0 versions is to get it out there so early adopters will start using it, filing bug reports, etc. It's the same reason the Linux kernel releases new even-numbered versions (2.x.0) before they're really ready for mainstream use. If they waited too long, people would avoid them, thinking they're "just development versions", and it'd take forever to get the bugs out. Unlike with commercial software, you need to know what you're doing when you use these open-source products directly, rather than using a packaged distribution. If you want a stable system, don't download GCC or Linux directly and compile from sources. Get the version that comes with your distribution.

MS, on the other hand, wants to get money and marketshare when they release all-new versions of their software. When they release a new version, they do so with the implication that this product is ready for general use, and that all the bugs are worked out (after all, you're paying a lot of money for it, so shouldn't the debugging be part of the price?). This is reinforced by the fact that most updates are not free.

If I buy a car, I expect it to work reliably, and not break down within the warranty term, as long as I perform the required maintenance. If a wheel falls off as soon as I drive out of the dealer's lot, they have to fix it at their own expense. I might even get a new car under the Lemon Law if this happens multiple times. What's more, if the car has any serious defects, these are usually fixed for free under factory recalls.

But when I buy MS software, none of this applies. There is no warranty whatsoever. If it doesn't work, there is no recourse. And if they release a new version that fixes a lot of problems, there's no guarantee it will be free. Did all the Windows ME buyers get a new version of Windows to fix that disaster of an OS? No, they had to upgrade at their own expense.

The bottom line is that the product MS releases is a shrink-wrapped product that is supposedly intended for direct use by the general public, which implies a certain level of fitness. GCC, on the other hand, does not release its product directly to the general public (though they're certainly free to download it and try it out if they wish). Its product is intended for use by software developers (who want to try out the latest, and possibly buggy compiler) and distributions. People who just want to surf the net or write documents should not be concerned with this, nor should developers who want to produce stable code. These people should all be simply using precompiled distributions, and using the software versions provided by them.

Re:kettle? black?

[Peter La Casse]

I love the open source movement but I wonder why the following comment is OK for open source projects and not close source?

quote "That said, no one should expect a "point-oh-point-oh" release to deliver the full potential of a product, particularly when it comes to a software system with the complexity of GCC."

I bet no one would dare say that about certain product from Redmond.

Is this an actual question, or clever use of irony?

It's said about all kinds of products from Redmond, all the time. Microsoft products epitomize the "point-oh-point-oh" view of a release.

Generally speaking, open source "point-oh-point-oh" products are more likely to be of high quality (than "point-oh-point-oh" closed source products), because many open source products have had a long and extensive life in "zero-point-whatever" land prior to their first "point-oh-point-oh" release.

Re:kettle? black?

[labratuk]

The gcc folks aren't asking for $300 for it.

They're not trying to force customers to switch to it.

And they're being honest about its capabilities.

Like a baby

[d_54321]

Like a baby, we won't really appreciate its value until it's matured a bit.

And if it dies, we'll be left with a lot of jokes

The value of a baby

[Laxitive]

"Like a baby, we won't really appreciate its value until it's matured a bit."

Seriously, this is why I don't appreciate babies. At least after about 4 or 5 years, they're useful for mild manual labour. Sure they'll complain and cry, but all you gotta do is tie their dishwashing to the number of fish heads they're allotted that week. Works pretty well, I gotta say. Anyway, at least they're not a net productivity drain like babies are.

Anyway, what I mean to say is: from your description, it looks like I'll be staying away from GCC 4 for a while, too. Goddamn babies.

-Laxitive

Re:The value of a baby

[CoderBob]

Don't forget that you can chain them to whatever equipment they will be operating by that age. You don't have to worry about them ripping the chain off yet!

Re:The value of a baby

[Momoru]

Man one of the moderaters today must be a new parent who hasn't gotten any sleep lately...all the baby jokes are being modded troll, have a sense of humor folks, or at least mod offtopic!

Re:The value of a baby

[Andrewkov]

No, once they get a job and move out, then you can really appreciate them!

Re:The value of a baby

[MarkCollette]

My Dad's favorite story, that he tells to everyone, is about how, when I was 4, I was washing the dishes, and asked for a break, so he let me vacuum for a while, and then I went back to doing dishes.

Kind of a weird review

[Just Some Guy]

As far as I'm concerned, unless you're using "-Os" because you're deliberately building small binaries at the expense of all else - say, for embedded development - the resulting binary size is completely irrelevant as a compiler benchmark. What if the smaller result uses a slower, naive algorithm (which in this case would mean choosing an obviously-correct set of opcodes to implement a line of C instead of a less-obvious but faster set)?

Second, the runtime benchmarks were close enough to be statistically meaningless in most cases. The author concludes with:

Is GCC 4.0 better than its predecessors?

In terms of raw numbers, the answer is a definite "no".

My take would have been "in terms of raw numbers, it's not really any better yet." It's close enough to equal (and slower in few enough cases that I'd be willing to accept them), though, that I'd be willing to switch to it if I could do so without having to modify a lot of incompatible code. It's clearly the way of the future, and as long as it's not worse than the current gold standard, why not?

Re:Kind of a weird review

[larien]

Smaller binaries = quicker load time (less disk I/O or memory being moved around) and smaller memory footprint. Yes, this is mostly in embedded apps where memory sizes might still be in KB rather than GB, but if you're analyzing performance, memory usage is relevant, even if it may not be your primary concern.

Re:Kind of a weird review

[MORB]

It's a very weird review.

I find it strange that the guy didn't mention the new autovectorisations optimisations that have been added (granted, they are still young and far from complete in 4.0 from what one can read on the gcc wiki).
After all, the speed of the generated code seems to be his main concern.

However, not a single word about other useful and interesting improvements and new features.

- Faster C++ compilations, especially with -O0. For this alone, this makes this release very worthy for C++ developers.

- Ability to define which symbols to exort and not to export in shared objects (.so). It won't mean anything for the end-user right now, but down the line, things like KDE that are written in C++ and uses a lot of shared objects will see their size and loading times decrease notably thanks to this.
Of course, they first need to do the necessary changes on their side to take advantage of this.

- Compile-time memory and pointers debugging and protection, using a new library called libmudflap.
This should prove easier to use and much less of a performance hit than tools like valgrind, as well as probably not too hard to port to windows.

Also, he doesn't talk about how much GCJ got upgraded for 4.0. They completed the merge with classpath, added the ability to gcj to compile whole .jar as native .so, and improved the way native and non native java code works together, up to the point that it can run some big applications like eclipse out of the box.

Basically, this is a review form a gentoo end-user, who as such consider gcc only from the performance standpoint.
Don't forget that the main target audience of compilers are developers, and for developers, gcc4.0 is a very attractive release.

Re:Kind of a weird review

[Anonymous Coward]

Someone already mentioned memory footprint, but missed the main issue with memory footprint - *cache* usage. If you're constantly getting Icache misses because the binary itself is too big, performance will suffer.

If you don't believe me, look at the work that went into the EPIC architecture purely for reducing code size (instruction word templates) or for keeping code size manageable in the face of compiler optimizations (hardware support for register rotation and modulo scheduling).

Re:Kind of a weird review

[ari_j]

See, I just thought he looked at the wrong numbers.

Re:Kind of a weird review

[Waffle Iron]

the resulting binary size is completely irrelevant as a compiler benchmark.

As the ratio of raw CPU MIPS to memory bandwidth and latency continues to increase, systems lean more and more on caches to compensate. Since larger code eats up more of the scarce cache resources to do the same job, small code can be more important than code with the lowest raw instruction clock count. This can be especially important in C++, where redundant code generated by templates can really get out of hand if not properly controlled.

Re:Kind of a weird review

[dpilot]

Anyone have a feel for where in X86-land cache size becomes a significant factor, driving -Os instead of -O2? For instance, if anyone is still running a 486 box as a firewall or router, I'd bet that -Os would be a better choice. But what does the line look like, when does a cache become big enough to become a win for -O2 and -O3?

Re:Kind of a weird review

[Just Some Guy]

I understand that, but I can quite easily imagine the inner loop of a compute intensive task that might see a huge benefit from filling 90% of available cache with a larger number of more efficient instructions instead of 70% with a small number of slower opcodes.

I'll admit that's probably not the most common case, and for general use then your scenario would probably give better system wide performance. Still, it's not really possible to say that smaller (or larger) binaries are "better" - there're too many other variables to account for.

Re:Kind of a weird review

[TheRaven64]

Additionally, smaller binaries = less instruction cache space required, which can potentially be a huge performance benefit (although only in some cases).

Re:Kind of a weird review

[dubious9]

and smaller memory footprint

Not necessarily. The smaller program could use more naive methods of memory allocation and use. Additionally, the program could implement look-up tables instead of dynamically calculating values, etc.

The instruction size may be smaller, but the data size, and hence the total memory footprint, isn't necessarily so.

Re:Kind of a weird review

[Anonymous Coward]

You'd think that -Os and -O1/-O2 would be orthogonal options and not either/or. Why disable all high optimizations just to keep code size down?

Re:Kind of a weird review

[dpilot]

-Os is orthogonal to the others, just like they're orthogonal to each other. -Os is like -O2, except that 4 (?) specific optimizations are turned off that increase code size. Take the 486 with its 8k L1 cache, for example. What good is an optimization that increases inner loop speed, if it makes the code so big that the inner loop won't fit in the L1, any more? You would be better off having less optimized code that fit in L1, to avoid cache thrashing.

Re:Kind of a weird review

[Anonymous Coward]

Are you understanding "orthogonal" to mean "exclusive of" instead of "independent of"?

If I want highly optimized but small code, I'd like there to ideally be a flag to turn off size-increasing tricks at any level of optimization (e.g. -O2, -O3, -O4), now and in the future. It sounds like you're saying that "-Os" currently overrides any other "-O" flag and selects "-O2"-like behavior.

Re:Kind of a weird review

[dpilot]

In this case, "exclusive of". I'm under the impression that you can have one "-O" followed by "0"-"3", or "s". In other words, "-Os" isn't a modifier, it's one of the set of "-O" options. I'd guess that anything -O3 adds to -O2 increases code size, as well as the 4 optimizations of -O2 that are turned off for -Os.

Oustanding!!!

[Anonymous Coward]

This is just what Linux needs more bloat and less speed.

Oh well, release early, release often. Especially when you don't have improvements to release.

The ? operator

[shreevatsa]

The worst part is that they now say that the

<?

,

>?

,

<?=

and

>?=

operators are deprecated, and will be removed. Damn, I liked them so much. Sure, they weren't part of the standard, and only a GCC extension, but it's just so much more fun to say

a = b <? c

than to say

a = min(b,c)

or even

a=b<c?b:c

. The best use was saying

a<?=b

instead of the painful

a=min(a,b)

.

Re:The ? operator

[Anonymous Coward]

min(you should get, out more)

Re:The ? operator

[keshto]

Dude, you've never coded in a commercial environment , have you ? Or are all your company's projects meant to be compiled by a specific version of gcc only, regardless of the OS and architecture? I use gcc exclusively these days, but it's for my research. Back when I was working, we had to code for both VC++ and g++ . Atleast, the ones of us who worked on core-engine code. Fixing some moron's VC++ -specific idiocy sucked.

Re:The ? operator

[Anonymous Coward]

Sure, they weren't part of the standard...

Doesn't that violate the purpose of having standards? Remember Microsoft's "Java"? Their CSS/PNG-rendering in IE? Their new "XML" proposal?

a = b <? c
a = min(b,c)

The latter is far more clear, IMO. Anyone can look at it and guess that it returns the minimum of b and c. The first? I'd have to look it up in the documentation.

Re:The ? operator

[City Jim 3000]

I'd say "thank god" after reading that text. And mod your comment "funny".

a=min(a,b)

that is one of the most self-descriptive statements i have ever seen.

Re:The ? operator

[Taladar]

Just write your own little preprocessor in ANSI C or Perl or some equally portable language to transform your code to standard compliant code.

Re:The ? operator

[cant_get_a_good_nick]

It's a joke son, ahh I say it's a joke son.
-- Foghorn Leghorn

If anything, I saw it as a subtle jibe at the GCC folks for including something non-standard such as that for such little benefit.

Re:The ? operator

[jay-be-em]

Turn on your sarcasm detectors folks.

Re:The ? operator

[fred9653]

... unless a is a pointer to a tcp-connection class and b is a pointer to an udp-connection...
What looks like a self-descriptive statement doesn't have to be self-descriptive.
=> DO NOT TRUST SUCH STATEMENTS - THEY WILL TURN ON YOU AS SOON AS THEY CAN!!! :)

Re:The ? operator

[shreevatsa]

I don't get it. I was very serious when I wrote that, still this comment has 60%Funny, and even 20%Troll.
In case you were wondering why anyone would want to use a=min(a,b), you really haven't programmed enough. To take a simplistic example, how would you find the largest integer in an array? (Sure, you can just #include , then say *max_element(a,a+N) and be done with it, but let's suppose you don't want to do that...)
Well, the way to do it would be to write a loop like this:

int largest = 0;
for(int i=0;i<N;++i)
largest=max(largest,a[i]);

I really think it's faster and better to code the last line as largest>?=a[i]. There is less unnecessary clutter.
Oh well. I guess this comment will now lose all its Funny mod points, but what the heck.

Re:The ? operator

[joss]

Dude, I like terse code as much as the next guy, probably more [especially if he's a java fan], but its also kinda nice to maintain code that doesnt look like line noise. I thought you were joking too. Your example is actually rather kind on max() since it comes from some header somewhere and there may be issues with the way it was defined, even so...

Re:The ? operator

[Heywood Jablonski]

The worst part is that they now say that the <? , >? , <?= and >?= operators are deprecated...

That's because they were conflicting with the new gphp front-end.

Re:The ? operator

[Phleg]

If I ever see a developer do something as stupid as this on a job application, there's no way they will ever get a job working for me.

Having clean, readable code is far, far more important than saving a few minutes in total in a project. Using compiler-specific features is generally frowned upon, but acceptable in cases where there are significant performance or time gains. Using a compiler-specific alias to save yourself a few extra keystrokes at the extreme cost of readability is just being lazy, and not thinking about how that code will be maintained in a year.

I feel the same way about the ternary operator, actually. There are a few cases where it's clear enough to be used, and where it saves several lines of typing. However, 95% of the time that people use it, it only makes the code impossible to understand.

Re:The ? operator

[zorander]

Yes. So do I. That's why I write code in ruby or python.

I wish that people would stop trying to make C something it's not by adding shortcuts and fancy operators. If you really need it, write yourself a preprocessor, compile, and build it as part of your build cycle. It's not that difficult to do, especially with the help of a scripting language.

C is meant to be fast and standardized. Anything that impedes those goals should be avoided. This included.

You'd probably like ruby--it's good at making really pretty, terse, readable code. Give it a look sometime.

Re:The ? operator

[owlstead]

Darn, I am using the ? operator to maybe print something on screen. Now I'll have to rewrite all my code. Oh wait, I'll create a macro for it to clear things up...

Re:The ? operator

[owlstead]

In other news, slashdot ate my "<".

Re:The ? operator

[Rhesus Piece]

You know... funny doesn't always mean
we're laughing _with_ you. ;-)

Re:The ? operator

[Anonymous Coward]

> int largest = 0;
> for(int i=0;i largest=max(largest,a[i]);

Oh yeah, that's real tough to write too. Your post was modded funny because people are laughting AT you.

Re:The ? operator

[makomk]

Actually, I think the fact that it no longer accepts casts as lexpressions is pretty annoying, because last time I looked it stopped Xine from compiling. Unless there's some switch to enable this that I don't know about...

Re:The ? operator

[makomk]

See this bug report. Someone less lazy than me has written a patch...

Re:The ? operator

[mjc_w]

My objection to the code is that it assigns a value to largest even when it doesn't change. My preference is

int largest = a[0]; /* assumes N > 0 */
for(int i=1;i<N;++i)
/* largest=max(largest,a[i]); */
if (a[i] > largest ) largest = a[i];

BTW, I really like the ?: operator. I even like to use it nested. However, I am always careful to have one item (condition or expression) per line, use lots of parentheses, and indent like if-then-else.

Do the new models replace or confuse old ones?

[expro]

I agree that this compiler is a cornerstone of free software.

But it was very frustrating to me to try to port the compiler to a new platform by modifying existing back ends for similar platforms.

After spending a few months on it (m68k in this case), I could not escape the layers of hack upon cruft upon hack upon cruft, that made it extremely difficult to make even fairly superficial mods because everyone seemed to be using the features differently and all the power seemed lost in hacks that made it impossible to do simple things (for me anyway). I am quite familiar with many assemblers and optimizing compilers.

I hope that the new work makes a somewhat-clean break with the old, otherwise, I would fear yet another layer to be hacked and interwoven, with the other ones that were so poorly fit to the back ends.

I suspect that not all backends are the same and perhaps the same experience would not be true for a more-popular target, but it seems to me it shouldn't be that hard to create a model that is more powerful yet more simple. Such would seem to me to be a major step forward and enable much greateer optimization, utilization, maintainability, etc.

-ftree-*

[Anonymous Coward]

The whole point of gcc4.0.0 is the tree-ssa thing. The author of this test didn't seem to notice that this stuff doesn't get enabled in -O2 nor -O3, but does have to be enabled by hand. This includes autovectorization (-ftree-vectorice) among other things which may make a difference.

If I was him, I'd repeat the tests again enabling the -ftree stuff when building with gcc4.0.0.

Re:-ftree-*

[Navreet]

mod parent up!

This is true! I gained a 20%+ boost [with my personal project] when I compiled with the -ftree-vectorize option.

Anyone know why this isn't included in -O2?

Re:-ftree-*

[Anonymous Coward]

Because it guesses what should be vectorizeable. If it guesses wrong your program will blow up.

My conjecture is that they require it enabled by hand so that people who know what they're doing enable it, watch what code blows up, then produce intelligent bug reports that can be directly linked to the vectorization and therefore fixes can be produced for 4.0.1

Re:-ftree-*

[Florian Weimer]

The whole point of gcc4.0.0 is the tree-ssa thing.

True, this is the major infrastructure change which justified the "4".

The author of this test didn't seem to notice that this stuff doesn't get enabled in -O2 nor -O3, but does have to be enabled by hand.

No, most tree-ssa optimizers are enabled implicitly at -O2 (they replace quite a few of the old RTL-based optimizers). Only some numerics code can benefit from loop autovectorization (which has to be enabled explicitly; for most source code, it just increases compile time).

Re:-ftree-*

[Anonymous Coward]

If I were you, I would know that "you were he" and "I was him" are. For suggesting "I was he" or "you were him", you were wrong.

Re:-ftree-*

[Anonymous Coward]

When using forms of the verb "to be," both the subject and the predicate nominative should be in the nominative case (I, you, he, she, it, they).

Re:-ftree-*

[multipart]

In fact most -ftree-* options are turned on at -O1. At -O2 you get more sophisticated alias analysis and a few passes work harder to try and squeeze out some more optimization opportunities. The differences between -O1 and -O2 for the RTL optimizers is much more significant.

More is Slower???

[Nom du Keyboard]

If you compile a great deal of C++, you'll want to investigate GCC 4.0.

So the more code you have, the more you want it to run more slowly. Perfect sense.

Re:More is Slower???

[jensend]

He didn't say if you *run* a lot of programs written in C++, he said if you *compile* a lot of C++. The performance of the generated code is roughly the same (slightly more often worse than better), but the compile time is considerably better. (The review linked to doesn't show this, but that's because it only includes one comparatively small c++ program; other people are showing huge improvements.)

Re:More is Slower???

[Anonymous Coward]

I guess you didn't notice that most of the benchmarks are C, not C++ and it is faster for C++. Well, I hope you didn't.

when? why?

[ChristTrekker]

At what point (of 3's evolution) would you say it surpassed 2.95? Why?

Re:when? why?

[stilwebm]

I would have to say the breaking point was when major distributions began using it. There were some bumps in the road and binary compatability issues initially. However, making GCC 3.x the default compiler signalled stable kernels and system libraries could be compiled with GCC 3.x. Widespread adoption led to more improvements, especially with code that would not compile with anything >2.9.5.

Re:when? why?

[ChristTrekker]

OK, that sounds like a reasonable metric. Any idea about when that was? 3.1, 3.2? Were the binaries produced at that point smaller/faster than 2.95-compiled binaries as well, or do you believe it was primarily an issue of stability?

Re:when? why?

[stilwebm]

GCC 3.0 was included in RedHat 7.2 but GCC 2.9.6 was the system compiler. That was some time in early 2001. In September 2002, RedHat 8.0 was released with GCC 3.2 as the system compiler. As far as I know, it was around that time that SuSE switched to 3.2 as well.

Re:when? why?

[HuguesT]

It took a while to surpass 2.95.3 in performance, I think 3.1.x ; however if you compile a lot of C++. The 3.x series was much more ISO-C++ compliant.

The 2.95.x series is still unmatched for speed of compilation I believe.

Nice analogy...

[DarcSeed]

Like a baby, we won't really appreciate its value until it's matured a bit

I'll just have to make sure you never babysit for me, if babies are that value-less to you.

Re:Nice analogy...

[Narchie Troll]

Babies aren't even useful as food or fuel.

Re:Nice analogy...

[Just Some Guy]

Lighten up, Francis.

Signed, a parent of three.

Re:Nice analogy...

[sc0ob5]

I think What he means is that like a child, you can see the potential there ready to grow into something great. Probably should have said something like "Like a baby, we won't really see it's real potential until it has matured a bit". Still it's a silly analogy.

Anyway, I am looking forward to 4.1. I'm not sure if I am game to compile my system with 4.0 until a few more people do it and I hear a little more about what breaks.

Re:Nice analogy...

[Anonymous Coward]

Well, it depends on how you pack them.

What the hell?

[oGMo]

This is the stupidest review of GCC4 I can imagine. I won't go so far as to say typical gentoo stereotype focusing on lots of flags to get "really fast" results, but you know some people are thinking it.

Where are the C++ benchmarks? That's what's supposed to be big in GCC4. Compiling C++, and doing it faster than GCC3 did (which isn't hard). How fast does this compile KDE? Qt? How big are the binaries? etc. I see all of ONE compile time statistic, and that's on the linux kernel.

WTF is this? Can someone with a clue please do a real review?

Re:What the hell?

[Kupek]

One of the major changes in the 4.0.0 release is the internal reorganization that allows for more aggressive optimizations. Hence, he tested how the optimized performance of the latest 3.x versus 4.0.0. How do you tell the compiler to optimize? Well, you have to pass it "lots of flags."

Re:What the hell?

[oGMo]

This sounds like an architectural change rather than a "we added lots of optimizations" change. Perhaps if he implemented some aggressive compiler optimizations it would be fair. :-)

Re:What the hell?

[Anonymous Coward]

<flamebait>Who cares about C++ anyway?</flamebait>

If you are using Linux (mostly plain C, not C++) and GNOME (mostly plain C) and many other applications, you do not care that much about the improvements for C++. Instead, you want to know how GCC4 compares with older GCC versions when compiling standard C code. This article shows that one should wait a bit before switching to GCC4.

If you are using KDE, Qt and a lot of C++ applications, then feel free to switch to GCC4 now (well, once the GCC4 bug affecting KHTML has been fixed). But if you are like the majority of those using GNOME (or older WMs such as fvwm), then this article is useful and recommends that you wait for the next GCC release.

Re:What the hell?

[Kupek]

It is an architectural change - one big enough to warrant increasing from 3 to 4. But the author's question is "Are the optimizations better now?" to which he answers "No." But he also make it quite clear that in the future, they may be.

Re:What the hell?

[maxwell demon]

Actually, he would have to write the same optimization for 3.x and 4.0, in order to compare the difficulty. And, of course, he'd have to do that with at least two optimizations (better more), changing the order of compilers he implements them on, so the advantage of implementing the same optimization a second time would go to both compilers the same number of times.

non-x86 arch?

[ChristTrekker]

What about the performance on MIPS? PPC? C'mon, people...enquiring minds want to know!

Re:non-x86 arch?

[Locke2005]

It's slower on MIPS too... yes I believe the optimizations in 4.0 still need some work. However, if code is re-written to use the vector (SIMD) intrinsics, some algorithms may be faster.

Re:non-x86 arch?

[ChristTrekker]

I've always known that most people using gcc are probably on x86, but it would be nice to know some numbers. It would be interesting to know how well PPC has fared since Apple began contributing. I still use some 68k boxen at home, and have been wondering if upgrading gcc will result in smaller/faster binaries.

This is expected, I think

[diegocgteleline.es]

I found this in the osnews announcement

"Before we get a bunch of complaints about the fact that most binaries generated by GCC 4.0 are only marginally faster (and some a bit slower) than those compiled with 3.4, let me point out a few things that I've gathered from casually browsing the GCC development lists. I'm neither a GCC contributor nor a compiler expert.

Prior to GCC 4.0, the implementation of optimizations was mostly language-specific; there was little or no integration of optimization techniques across all languages. The main goal of the 4.0 release is to roll out a new, unified optimization framework (Tree-SSA), and to begin converting the old, fragmented optimization strategies to the unified framework.

Major improvements to the quality of the generated code aren't expected to arrive until later versions, when GCC contributors will have had a chance to really begin to leverage the new optimization infrastructure instead of just migrating to it.

So, although GCC 4.0 brings fairly dramatic benefits to compilation speed, the speed of generated binaries isn't expected to be markedly better than 3.4; that latter speedup isn't expected until later installments in the 4.x series."

Re:This is expected, I think

[Ian Lance Taylor]

That is only partly true. All gcc releases since 1.0 have integrated optimizations across all languages. What gcc 4.0 has added is a new, higher-level framework for language independent optimizations. The new framework, known as tree-ssa, permits more powerful optimization techniques, in particular some of the techniques which have been developed by the compiler research community since gcc was first written in the 1980s. The old language independent optimization framework, known as RTL, is still there and is still used in gcc 4.0.

Like a baby

[Anonymous Coward]

Like a baby, we won't really appreciate its value until it's matured a bit.

"Come here son. Did you know your mother and I almost decided to not keep you when you were born? You were just a baby at the time, you didn't seem to have any value. I mean, seriously, what use is there for a baby? I'm glad we didn't make that mistake.
Now go play outside and don't come back before dinner time, and pick up the trash when you leave."

There are a bunch of papers on Tree-SSA...

[tcopeland]

...on Diego's web site here.

It really does depend on the code

[DoofusOfDeath]

There was one test case I did for my own use. I've got a small C++ program that's computationally heavey and has a small working set of memory.

On that program (on a P4) I got an 11% reduction in runtime using GCC 4 vs. GCC 3.3.5. This was actually a big deal for me work.

The lesson here: You're mileage with GCC 4.0's improvements may vary from the benchmarks, and you might want to try it on your own code.

Similar results here.

[Anonymous Coward]

For C code gcc 4.0 produces noticably slower code than 3.4.3. (5-10% slower).

Maybe it's because of the different inlining-limit heuristics or something. Better stick to 3.4.3 if you want maximum performance for C code.

Any big spoilers in the review?

[GnuPooh]

I don't wanna read the review it reveals the ending or something. I mean what good is a compiler without some big unexpected surpises?

moronic review

[Anonymous Coward]

Typical ... "okay, like i compiled all my kewl apps that I like totally rice out with the optimization flags because it's all about optimization, and this new one didn't give me nothing. I mean, I didn't use that tree-ssa because well I didn't read about it or nuthin, and I don't do any C++ because KDE is so totally like windoze (Micro$uck, lol!) and C is where you learn about your system and all, so hey I want it all to be about C, and the buncha flags that make things go fast worked exactly the same as they did the last time, what's up with that lol!"

Re:moronic review

[ChaoticCoyote]

I have no clue what you're talking about.

One benchmark *was* C++ (povray), and, in fact, I use KDE as my desktop. It just so happens that most code in a distribution is written in C.

I have quite a bit of heavily-templatized C++ in my library and customer code, but it is either proprietary (under NDA) or unsuitable to timing. As I state in the article, C++ programmers should seriously consider GCC 4.0 for it's imrpoved compile times, if nothing else.

Re:Gentoo

[swotl]

What tests are you referring to?

"Like a baby..."

[Gannoc]

Like a baby, we won't really appreciate its value until it's matured a bit.

Are you kidding? Babies are worth $15,000-$20,000 easily, even if they're female. Once e-Bay stops being a bunch of pussies and we get some open bidding started, I expect their value to go up even higher.

Once again, we see that the ./ editors have no idea what they're writing about.

Re:"Like a baby..."

[Anonymous Coward]

Are you kidding? Babies are worth $15,000-$20,000 easily, even if they're female. Once e-Bay stops being a bunch of pussies and we get some open bidding started, I expect their value to go up even higher.

But keep those females in storage till they're 15 or 16, and just watch their value rocket! For an attractive specimen with genuine teeth and a certificate of virginity, expect bids to come into the range of $50,000 to $100,000. Depreciation is fairly nasty, though - used models typically fetch an order of magnitude less on the open market, and it becomes increasingly difficult to shift stock past the age of around 25.

Speed/Performance Benchmarks??

[torinth]

What's up with all these speed and performance benchmarks. I may be dead wrong (or at least outdated), but I thought GCC was developed with architecture compatibility, standards, and language features in mind--in that order. If you really want performance, you're usually better off using a commercial compiler targetted at a specific architecture, like Intel's. Did things change, or is this review completely missing the mark?

Re:Speed/Performance Benchmarks??

[tomstdenis]

Not always. Usually Intel's CC produces faster code except when you give it code [LibTomMath] that it can't efficiently optimize.

Also as he hates to have pointed out his options aren't always optimal.

Quite a few applications are faster with 3.4.3 on a P4 with "-fno-regmove" as well as -O3. My AES for instance goes down from >500 cycles/block to 380 cycles/block on my Prescott P4 with this switch.

380 cycles/block is faster than Intel CC v8.0 with "-O3 -xP -ip" by about 30 cycles/block.

Also the guy probably didn't try profiling. I can drop a fair chunk of cycles in doing ECC point multiplies on my P4 with GCC by doing a profiled build system. ...

ETC!

Tom

Re:Speed/Performance Benchmarks??

[Anonymous Coward]

Still, no reason to expect that GCC won't generate faster code over time. All that other stuff doesn't matter squat diddley if your compiler backend is still using optimization technology from the 1960s. One of the nice things about GCC 4 is that the introduction of SSA will allow a lot of nice new optimization algorithms. These are generic algorithms, not "OMG on stepping 5 of the Pentium 4 processor made in year 200x instruction Q runs 0.05% faster than instruction Z", which is what you might expect something like icc to do.

Re:Speed/Performance Benchmarks??

[ChaoticCoyote]

Ah, the problem in selectign benchmarks and compiler flags.

I tried to treat GCC 4.0 as if I were a "normal" user, throwing the "obvious" best flags at each application. If I select specialized flags for each application, someone inevitably complains "but real people won't do that!"

So I get bit no matter which flags I use.

Now, insofar as profiling an such, see my Acovea work, which is how I find the best options for compiling.

Re:Speed/Performance Benchmarks??

[tomstdenis]

My experience has been on the P4 that "regmove" is a broken optimizer. Specially coupled with the profiler I haven't seen much that is faster with it enabled.

But yes, your right that the actual algorithms will be sensitive to different options.

At the very least you should have done profiled builds though. that's where recent GCCs start to shine [specially on the branch sensitive P4].

Tom

Manners citation

[gammoth]

Like a baby, we won't really appreciate its value until it's matured a bit.

You didn't mean it, but you've managed to insult all past, present, and future parents!

Otherwise, thanks for the review. Consider yourself appreciated. Really.

Re:Manners citation

[ChaoticCoyote]

My, my how people latch onto the smallest things.

I have three great daughters, all very different, and I had no idea what they would turn out to be when they were born. One of the most fun parts of parenting is watching your kids emerge with time.

No one in my family is bothered, so I guess I don;t see where the insult lies.

Re:Manners citation

[gammoth]

Take my comment with a grain of salt. I cited you for bad manners. The subject line indicated--well, I guess failed to indicate--that I wasn't entirely serious.

However, let me elaborate. As your children's personalities emerge, does your appreciation of their value change? No, I suspect not. Their personalities develop, but I'm guessing you value them exactly the same. I'm also guessing you hold them in high, high esteem. I can tell from your post above.

The insult is that you've conditionalized the value of a child, and you've assoicated their value with that of a compiler! Perhaps a better phrase would have been, "we won't fully realize their personality until they've matured a bit." But that really doesn't work, either. We don't want a compiler with persoanlity as much as value.

But, hey, you're right. I nit-pick. Here's another peeve: I can't stand when people say, "I was babysitting my kids last night." Sorry, but you can't babysit your own children. Other people do that. You mind, watch, care for, or supervise your own children. You babysit for others.

I also can't tolerate the phrase, "the bottom line." It's such an insult to the other side of the conversation. It's saying, "I have the weight of rational economics on my side, and you just can't argue with that."

The truth is, you wrote a great review and you clearly know what your doing.

Re:Gentoo

[TelJanin]

Only on /. could this get modded up...

He's not a dumbass because he uses Gentoo. It's pretty obvious that he doesn't know what he's talking about. Straight from TFA:

Some folk may object to my use of -ffast-math -- however, in numerous accuracy tests, -ffast-math produces code that is both faster and more accurate than code generated without it.

"I don't know about you, but if I want my math done fast and wrong I'll ask my cat" - Anonymous

And some do both

[gr8_phk]

Some people think because they've got the best known asymptotic run time that they are done. Others reach that point and then tweak the implementation and compiler options to go faster yet. I had some nice code that ran decent, but I spent months (a free time project) to get it faster. The theoretical run time has not changed, but in practice it is now 2x to 3x faster than when I started.

What did I do?
optimized data structures (not algorithms)
moved a critical function from one class to another - still puzzles me why 25%
considered branch penalties
one batch of auto-generated C code - refined several times
rewrote some functions as plain C
rewrote one complex expression in asm

It's a lot of work, but I spent at least as much time considering algorithms prior to the optimization effort. Both strategies are important for making fast code.

Besides, in these benchmarks everything was the same except the compiler version...

Re:And some do both

[gfody]

moved a critical function from one class to another - still puzzles me why 25%

critical as in function-calling overhead is affecting performance? if you moved it from a big class to a little class you may have reduced the size of the stack that's allocated before calling the function.

Like a baby?

[gatkinso]

Like a baby, we won't really appreciate its value until it's matured a bit

Look, babies are great.... it is the teenagers you want to get rid of.

Re:Like a baby?

[Anonymous Coward]

Note the use of the word "matured", rather than "aged"; most pre-teens are more mature than when they become teenagers, I've found. Of course, since the creation of the "tween" demographic by Madison Avenue (who comes up with these names, anyway?), the pre-teen population has taken a nosedive, too. Hey, wait: maybe it's not the children, it's society!

Tree-ssa is in there

[jensend]

Unless the GCC documentation is very wrong, the only tree-ssa optimizations in 4.0 which don't get turned on by default at -O3 are -ftree-loop-linear, -ftree-loop-im, -ftree-loop-ivcanon, -fivopts, and -ftree-vectorize. It's true that some of these may be good optimization wins (probably increasing compile time in the process, but that's what the higher optimization levels are all about), but there are plenty of tree-ssa optimization passes being used in these tests.

Auto-vectorization, by the way, does not fall into a "obvious optimization wins which perhaps should be enabled at -O3 by default" category. It can bring very big performance benefits in some situations, but it should be used with caution.

Re:Tree-ssa is in there

[Dan Berlin]

of the ones you listed, only -ftree-loop-linear and -ftree-vectorize are not on by default. (you also missed a couple, though they slipped my mind)

4.0.0 broke backward compatibility big time

[cpghost]

Recently, a discussion took place on a FreeBSD mailing list wether the project wanted to use GCC 4.0.0 as the system compiler. Some objections where:

• KDE would not compile cleanly
• Most of the 12.000+ ports would need manual tweaking because of other incompatibilities.
• Some C constructs have been obsoleted, requiring huge sweeps over the existing BSD code base.

If I understood it right, We won't have a GCC 4.0.0 system compiler on FreeBSD anytime soon. Installing the gcc40 port is, of course, always possible.

Re:4.0.0 broke backward compatibility big time

[chrysalis]

gcc 4.0 just tries to follows standards. If something doesn't compile with gcc 4, don't blame the compiler. The source code was broken at the first place.

Re:4.0.0 broke backward compatibility big time

[mandolin]

If you actually follow the link, it looks like gcc4 was miscompiling bits of kde. Here is an example.

"not compiling cleanly" may have been a less-accurate description of the problem.

Re:4.0.0 broke backward compatibility big time

[ortcutt]

That's somewhat true, although GGC 3.* became a "standard" that people wrote the code too. Nobody is really to blame for anything. The source code wasn't any more"broken" than the compiler. It was just written to conform to GCC 3.*

Breaking backwards compatibility can be a good thing, but it requires time for people to adjust. So don't expect your distribution to use 4.0 for a little while.

Re:4.0.0 broke backward compatibility big time

[JoeBuck]

In the case of the KDE problem, there were two bugs, one of which was in KDE, but the other of which was in 4.0.0. So it sometimes is appropriate to blame the compiler. That bug is fixed in CVS and will be fixed in 4.0.1.

It should not surprise anyone that the first 0.0 release has some bugs. It's the first release of a compiler with a completely new optimization structure (tree-ssa). I would advise waiting for 4.0.1 for a production-quality release, or go with vendor patches (by making Fedora Core 4 with a 4.0.0 based compiler, Red Hat will probably shake out a few more bugs).

Re:4.0.0 broke backward compatibility big time

[multipart]

GCC 4.0.1 will fix a pair of bugs that make compiling KDE impossible. So in a couple of weeks your first point should be solved. The other two points could be a bigger problem. On the other hand, all the major Linux distros are going with GCC4 for their upcoming releases, so at least the code shared between the BSDs and Linux (e.g. most of GNU iiuc?) should already be "GCC4-proof".

Re:4.0.0 broke backward compatibility big time

[Anonymous Coward]

I thought forced upgrades is something Microsoft did, not the open source community. I guess I was proven wrong.

You know, I'm sick and tired of idiots who think some standard on a piece of paper is more important than real-world code. The fact of the matter is that there is a lot of real-world C code out there that has compiled just fine for years until the GCC developers got all prissy and started deliberately breaking code.

I'm sick and tired of patching just about every C program written more than two years ago just because the GCC developers decided to break code that compiled just fine.

To hell with the standards. I want something that compiles all of the open source code which compiled fine five years ago without forcing me to make huge patches in the name of standards.

If the standards do not reflect real-world code, they need to be rewritten.

Re:4.0.0 broke backward compatibility big time

[Laven]

Fedora Core 4 has been building everything with gcc4 for several months now. We fixed code in some cases where gcc4 could no longer compile, but cases were fairly rare. FC4 is shipping with KDE 3.4.0.

Re:4.0.0 broke backward compatibility big time

[Anonymous Coward]

If the standards do not reflect real-world code, they need to be rewritten.

This is, of course, pure nonsense. Many people got together and worked very hard to create the C standard (ditto the C++ standard). If you refuse to learn what is standard and what is not, this is YOUR FAULT. Compiler vendors all add mutually incompatible extensions that are not part of the standard. Should the standard incorporate all of these? No! Not only would that be idiotic, it would be physically impossible.

Standards are what make compatibility between compilers and even between the same version of a given compiler even a possibility. Not following standards (like that code you reference from a few years ago) makes it impossible. Period.

I'm actually still flabbergasted by your statement... Have you EVER tried to write code that works on multiple compilers?

Re:4.0.0 broke backward compatibility big time

[dvdeug]

The fact of the matter is that there is a lot of real-world C code out there that has compiled just fine for years until the GCC developers got all prissy and started deliberately breaking code.

It can be seriously complex to be bug-compatible with every random C compiler ever written; in many cases, it means you can't add many optimizations or fix things. If people expect optimization and support for new features, they're going to have to give up support for every buggy fragile piece of crap ever written. If you want the set of code you can compile to remain exactly the same, stay with the same version of libc and GCC.

Re:4.0.0 broke backward compatibility big time

[Anonymous Coward]

The fact of the matter is that there is a lot of real-world C code out there that has compiled just fine for years until the GCC developers got all prissy and started deliberately breaking code.

If it stopped compiling, it wasn't C code. It was some dialect of C with extensions. It probably wouldn't compile with ICC or MSVC either.

Re:4.0.0 broke backward compatibility big time

[be-fan]

Microsoft forces upgrade for the sake of forcing upgrades. GCC forces upgrades for the sake of fixing broken shit. That's a good thing, and the only way to ensure a quality product.

I have no patience for morons who can't write proper code. If you have to "make huge patches" to adhere to the standards, then your code was fucked to begin with. The C++ standard is now the better part of a decade old. Good, standards-compliant compilers have been available for four or five years. If your five year old code requires huge changes to compile on GCC 4.0, it was broken by design. There is no excuse for this sort of thing --- make sure your code compiles with a number of compilers before calling it done, and your code will generally be more compliant and more maintainable.

And I hope you realize, in retrospect, the idiocy of rewriting standards to kowtow to every moron who couldn't write a line of standards-compliant C code. Could you imagine the clusterfuck that would be the codebase of a compiler supporting such a standard?

Re:Do the new models replace or confuse old ones?

[Ian Lance Taylor]

The new tree-ssa optimization passes do not affect the backends. The backends continue to be written using RTL. It is very difficult to make a "somewhat-clean break" here, since that would imply rewriting or dropping every existing backend.

In other words, writing a gcc backend continues to be a relatively black art. That said, there is of course continuing effort to clean up the backend interface and make it easier to use and to understand.

Finally I'll note that the m68k is a very old processor and is one of the oldest gcc backends. It would be an odd choice to pick that backend to modify to support a new processor, unless the new processor is a direct variant of the m68k like ColdFire. For any other processor, you should certainly start by looking at a different backend. And, in fact, in general, I think you should write a new backend from scratch. I've done it both ways, and starting from scratch, while of course looking at existing backends, means that you understand all the code and you don't have a lot of cruft which is irrelevant for your processor.

off-topic: I don't like your baby analogy

[Anonymous Coward]

"Like a baby, we won't really appreciate its value until it's matured a bit."

I'd like to say "it's apparent you're not a parent," but instead I have to say: I hope you're not a parent. It scares me to think what you might mean by its "value."

[And no, I'm not a "fundamentalist" of any religious persuasion (including those which worship money and/or capitalism), in case you were wondering.]

What a crappy review

[Fefe]

Uh, and this review is helping us... how?

lame uses assembler code for vectorization. One of the new features of gcc 4 is the beginnings of a vectorization model. A good test for gcc 4 would have been to compile some C-only bignum libraries, and Ogg Vorbis! povray is also a good example, but then you need to test more than one specific test-run. Maybe gcc 4 makes radiosity in pov-ray 400% faster at a 2% cost in the rest of the code?

This guy is the Tom's Hardware of Linux reviews, except he doesn't have the annoying ads, and he does not split his lack of content over 30 HTML pages.

The new warnings of gcc 4 have helped me find a bug in my code. That saved me a week. Consider how much faster gcc 4 needs to make pov-ray or lame to save you a week of work!

gcc 4 can now reorder functions according to profile feedback. That should make large C++ projects faster. Also, the ELF visibility should make KDE start much faster. This should have been tested!

Please note that I'm not saying gcc 4 produces faster code. I don't rightly know. I do know it produces smaller code for my project dietlibc, where size matters more than speed.

Re:What a crappy review

[ChaoticCoyote]

It's odd, then, how LAME's performance was dependent on the compiler used to generate the code. If the C compiler is unimportant, why did GCC 4.0 turn in results different from GCC 3.4.3?

That said, you do have a valid point about the LAME benchmark using assembler in certain bits. I'll pick something else next time around.

The fact that GCC 4.0 loses ground on number crunching (no assembler) didn't seem to get your notice. And an increase in kernel size, plus longer compiles, isn't good news for kernel developers.

Re:What a crappy review

[Anonymous Coward]

The kernel uses assembler and gcc version dependent trickery all over the place and is thus not a good benchmark either.

Who cares about speed anymore?

[Stankatz]

When I saw "GCC 4.0 Review", I expected to see a review of the way the compilers (especially C++) handles the syntax. Is the compiler any closer to the C++ specification? Has it improved the way it handles templates? Is it likely to break old code? All he talked about was tiny little speed increases (or lack thereof). If a speed increase is less than 20%, it's probably not even noticable. And thanks to Moore's law, even a large speed increase will be irrelevant in a short time. I care more about my productivity as a developer.

Re:Who cares about speed anymore?

[pclminion]

If a speed increase is less than 20%, it's probably not even noticable. And thanks to Moore's law, even a large speed increase will be irrelevant in a short time.

What universe are you living in? Processor speeds are not doubling any more. Have you noticed than Intel failed spectacularly to make a 4 GHz chip?

Besides, Moore's law has to do with transistor densities, not clock speeds.

I care more about my productivity as a developer.

So you write grossly inefficient code, banking on the fact that processors will get faster? You're in for a rude awakening.

Re:Who cares about speed anymore?

[Stankatz]

Somehow I knew that mentioning Moore's law on /. was a bad idea ;) But seriously, did you read my post? I don't "write grossly inefficient code, banking on the fact that processors will get faster". Do you write inefficient code, banking on the fact that future compilers will magically make it 10x faster?

My main point was about the standards compliance of the compiler. Frankly, I couldn't care less if GCC 4.0 produces 5% faster or slower code. A couple years ago, I tried to move a project from GCC to VC++ 6. After a couple days of rewriting perfectly valid code to get the idiotic VC++ compiler to compile it, I gave up. I didn't care that VC++ was faster or made faster code. I wanted to be able to write good code.

Re:Who cares about speed anymore?

[Dr. Sp0ng]

A couple years ago, I tried to move a project from GCC to VC++ 6. After a couple days of rewriting perfectly valid code to get the idiotic VC++ compiler to compile it, I gave up. I didn't care that VC++ was faster or made faster code. I wanted to be able to write good code.

VC6 has crap C++ support, as does VS.NET 2002. 2003, though, is quite a good C++ compiler, more or less as good in terms of standards support as gcc (and much better in terms of optimizations).

Re:Who cares about speed anymore?

[Profound]

If your work as a developer looks like:

do {
Code
Compile
Test
} while (!done);

Then a faster compilation time will help you, not just saving time but keeping your focus due to shorter turn around.

I get a slight feeling of hesitation before making a small but useful change in a toplevel header file because of long compilation times. In fact, this quick turn around in the loop above is one of the reasons you can develop faster in interpreted languages. It is also an advantage of Java over C++

You mean GDC

[shenanigans]

Those who have heard of it and looked into it take it seriously - but most haven't. Sure, it was mentioned on /. a while ago, but that was when the compiler was way back in beta-land - and it was announced as something completely new, so you can't blame people for not taking notice.

Now it's closing in on 1.0, and is very usable. Give it a try if you haven't already. I used to be a C++ guy. After using D for six months, just looking at C++ code makes my eyes hurt, nevermind coding in it.

Re:You mean GDC

[PierceLabs]

What does a Game Developers Conference have to do with this?

Funny you should say that - a story about sprintf

[Szplug]

A prospective professor gave a talk at our school, he'd been working at some grid computing lab. Well their code was underperforming, so they profiled it and found that sprintf was taking 30? 50? 70? % (I forget) of their code time - the machines had to communicate with each other a lot, and they used sprintf to serialize. (It's an easy fix - C++'s stream operators are much faster, since the type is known at compile time.)

Oh yeah, also, for Quake 1, John Carmack hired Michael Abrash, an assembly language guru, to help out. Well Abrash found that GCC's memcpy() (or whatever it was) was copying byte-by-byte instead of by word (or something, I don't remember) and his reimplementation of that alone, doubled the frame rate!

Just some interesting counter examples to keep in mind :)

Is this test misleading...

[bigmike_f]

It is from my understanding that the usage of a compiler is to obtain extreamly streamlined code for the instruction set of the chip. To have fast compile times are fine if one is developing code that needs fast turn arround time. (Things like, will this bug fix address the issue.) However, when a compiler really shines is figuring out that a specific processor is 0.3% faster when this instruction is called. (And it's called 10e4 thousand times.) So spend some time finding that bit of code. In this article that is not disscussed. In my opinion that is where a compiler should be judged.

Re:Is this test misleading...

[Stankatz]

A 0.3% speed increase multiplied by 10e4 is still 0.3%, which is still unnoticable. I think a compiler should be judged primarily on how it affects the productivity of the developer. If it doesn't handle standard C++ (or other language), then you have to spend half your time "porting" C++ to C++. Compile time also comes into play, especially in large projects where compile times can be several minutes long.

Re:Is this test misleading...

[Miniluv]

Bah, compile times of several minutes are very manageable. Where compile time really comes into play is when a project goes from taking an 1:15:00 to 45:00. Thats a noticeable productivity gain.

A lot of that speedup can be gained with tools like distcc, faster processors, and faster IO. Simply buying a faster PC for our Windows developer, he went from a P3 500 to a P4 3.2Ghz, trimmed 60% or so out of his compile times. Granted it went from around 10 minutes down to around 4, but he tends to recompile his stuff a lot, so thats still a meaningful gain for him.

Users??

[bobbuck]

Does Gentoo have users? I though they only had installers.

Re:Users??

[Cobron]

I don't have mod points so I'll do the next best thing: LOL! :-)

Re:Users??

[aled]

don't you know anything? They don't have users, neither installers. They just have sources. Only sources. In packages.

Re:Users??

[bobbuck]

It was supposed to be a joke. See, the user is really just an installer because he spends all his time compiling and installing and never actually gets to use it. Lighten up.

Re:Users??

[aled]

Mine too ;-). I was to add that it must be lonely distribution with only sources and no binaries.

Observations on Apple's GCC4 release

[Paradox]

It isn't a huge deal for most people, but it seems like the new GCC is singificantly better at optimizing for the PowerPC now.

I've been working with the GNU GSL on my mac a lot, and I recently updated to Tiger. The first thing I noticed when I recompiled the GSL with Apple's modified GCC4.0 is the significant and noticable speed increase. With this intense math stuff, doing SVD on 300x200 matricies, and it's shocking how much faster it is. I went from 3-5 seconds down to less than one.

I am not going to post any hard numbers because I haven't rigorously compared them yet, but I'll make some formal comparisons this week.

Re:Observations on Apple's GCC4 release

[bluGill]

Don't forget that until reciently few people cared about ppc compared to x86 optimization. Now that Apple is using gcc all over, and making money, they care enough to make ppc optimization good. I suspect there was a lot of "low hanging fruit" that apple could use right away.

Re:Observations on Apple's GCC4 release

[ControlFreal]

If you're performing large (block-)matrix operations, you might want to take a look at ATLAS; ATLAS basically is an automatically tuned version of LAPACK and BLAS. Not only does it use vectorization on CPUs that support it, it also takes the sizes of your L1 and L2 caches into account, by reordering the matrix operations such that the cache hit rate is highest.

ATLAS doesn't depend much on the compiler's optimization abilities; most of it is generated as assembly. And it's a _very_ realiable thing: big commercial tools such as MATLAB are built on top of (slightly modified versions of) ATLAS.

As for you; the ATLAS build system definitately supports AltiVec things.

Re:Funny you should say that - a story about sprin

[Procyon101]

ACK! If 70% of your time is spent in a serialization function call, FORGET about optimizing the function call.... You are WAY too fine grained in your algorithm for effective parallelization. He's have been better off running the whole damn thing serially on a single box methinks. His fancy grid algorithm spent more time doing "grid" stuff than working on his problem!

No, the third run is for finding bugs

[Bananenrepublik]

If your compiler compiles correctly, a program (leaving floating point inaccuracies aside) should produce the same result no matter what compiler it is compiled with. I.e. a gcc 4.0 should produce the same results no matter if it's itself compiled with 3.4.3 or 4.0.

Re:No, the third run is for finding bugs

[Anonymous Coward]

Yes, as long as it wasn't miscompiled.

Historically, GCC tends to bring out the worst in compilers. That is why when you build GCC, the system compiler will be used once, /without optimizations/ to produce a slow GCC 4.0 which can be used to compile itself. This is done twice (stage 1 compiles stage 2 and stage 2 compiles stage 3) so that 2 and 3 can be compared to ensure that there were no miscompilations, as it is unlikely that a miscompiled compiler will produce correctly executable machine code that replicates exactly.

Unlikely but possible. Look for the paper "Reflections on trusting trust" for a beautiful hack involving intentional miscompilations. The author basically changed the compiler so that when "login" was being compiled, the compiler inserted a back door. And when a new compiler was being compiled, the compiler would insert the code to insert the back door and to change the next compiler. And then no matter how much you checked teh source to either login or the compiler, you would never notice the back door.

Re:No, the third run is for finding bugs

[petermgreen]

you mean http://www.acm.org/classics/sep95/ ?

Re:No, the third run is for finding bugs

[confused one]

If only that were true... I know a guy who's proven otherwise and is currently documenting where it's different.

What the LFS people have seen is that you must compile the tool chain (including the libraries) 3-4 times in order to guarantee purity. Each pass is compiled with the results of the previous pass...

Still generating 386 assembly?

[heroine]

It seems aside from extremely rare cases, gcc still generates exclusively 386 assembly. The commercial compilers have long since migrated into MMX, MMX2, SSE, SSE2, 3DNow instructions. The new versions of Windows software are all compiled with modern instructions but GCC and all of Linux is still using old 386 instructions.

If the amount of energy being spent on redesigning the kernel architecture, redesigning the compiler architecture, and redesigning the command usages was spent supporting new instruction sets, it could probably catch up to MSVC from 2000.

It's sort of sad that instead of improving the computer's ability to perform a certain amount of work in a certain amount of time, all the energy in GCC has always gone towards the study of compiler design itself.

Re:Still generating 386 assembly?

[Anonymous Coward]

Errrr....

-march=pentium4

Re:Still generating 386 assembly?

[Ian Lance Taylor]

You need to read up on the -march, -mfpmath, -mmmx, -msse, -msse2, -msse3, and -m3dnow options.

If you build gcc yourself, you can even make them the default by configuring with an appropriate --with-arch option.

Re:Still generating 386 assembly?

[cpghost]

Yes, you can do that. But for people compiling and then releasing complete distros, it is best to stick to a more conservative instruction set. Think VIA C3, GEODE, and other low-power or fanless CPUs out there that don't support the whole fancy P4 instruction set! People willing to install a standard distro on those boxes would be pissed off, if the bootloader or kernel freezes, just because of some weird instruction.

It can be argued that it is the distro-maker's responsibility to switch gcc to a more conservative setting before building the distro, but it's 1. easily overlooked and 2. still not the default, once installed (which would break things again on those boxes).

To rephrase a known strategy: "Be liberal in what you accept, be conservative in what you output" (and let the users turn on optimizations, don't force it on them)!

Re:Still generating 386 assembly?

[bjb]

You need to read up on the -march, -mfpmath, -mmmx, -msse, -msse2, -msse3, and -m3dnow options.

I believe -march implies combinations of the flags above. For example, if you say -march=pentium4, I think this implies -mmx, -msse, -msse2.

Is that C or is it...

[sboyko]

You must have loved APL. ;)

Re:x86 vs GCC

[Urusai]

Yeah, didn't Itanium replace that tired old CISC architecture?

Sure, after you invent a time machine

[bluGill]

Many tasks involve computation on data gathered. I cannot start my program 10 minutes earlier because the data has not arrived yet.

KDE hates gcc 4.0

[bluGill]

There is a configure check in KDE, if your compiler is gcc 4.0 it will fail in the ./configure step. This bug is acknowledged by the gcc developers, who are working on it. (They have some test fixes, but are not confident in them yet)

I'm sure kde will love 4.0.1 if the bugs are fixed, and the compile speed is still as fast, but 4.0 is a no-go.

Re:KDE hates gcc 4.0

[Anonymous Coward]

This bug is acknowledged by the gcc developers, who are working on it. (They have some test fixes, but are not confident in them yet)

Actually, they already consider it fixed - the fix has been in since April 22: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973

Well at least it isn't like the disaster of 2.96

[stry_cat]

At least we don't have to worry about the horror of having to downgrading from 2.96 to 2.95. Was I the only one about to give up on Linux after that disaster? Just for reference: http://linux.slashdot.org/article.pl?sid=00/10/07/ 0027218&tid=106

No danger

[SuperKendall]

I don't get it. I was very serious when I wrote that, still this comment has 60%Funny, and even 20%Troll. ....
Oh well. I guess this comment will now lose all its Funny mod points, but what the heck.

To the contray, now it's even funnier.

A Modest Proposal

[Anonymous Coward]

You truly undervalue babies in your statement. I suggest that you read
A Modest Proposal (1729) by Jonathan Swift.

Linux 4.6.11.8

[drb000]

Whoa. This guy has something more valuable that benchmarks to share.

Re:Well at least it isn't like the disaster of 2.9

[turgid]

At least we don't have to worry about the horror of having to downgrading from 2.96 to 2.95. Was I the only one about to give up on Linux after that disaster?

I didn't have to worry about that horror at all and I'm into my 10th year of using Linux now. You see, gcc-2.96 was a RedHat-only branch of gcc and it was broken. So you tried RedHat once and were put off Linux? RedHat may be corporate America's standar d Linux, but it's by no means the only Linux or the best.

Re:Do the new models replace or confuse old ones?

[bani]

coldfire is becoming an increasingly important architecture, and gcc could do well to support it. problem is there's a lot of coldfire variants with all sorts of nifty stuff, all different. ("you are in a maze of twisty passages, all different. you might get eaten by a grue.")

a simplified backend would help greatly in porting to these architectures. especially if the autovectorization could be mangled to support the EMAC in some of the coldfire variants.

AMD Opteron

[RichiP]

After reading the results, I'm wondering if AMD invested money and human resource in helping the GCC team in developing their compilers. If they are, then what is the reason behind the poorer performance as compared to an older version. If they're not, why? Don't they have a vested interest in seeing this compiler work better on their hardware platform?

Re:AMD Opteron

[cimetmc]

Most of the work for AMD64 support in GCC was spondored by AMD, but actually executed by Jan Hubicka (SuSE). Other companies were involved as well as shown on the AMD64 web site http://www.amd64.org/
As for GCC 4.0 being slower than 3.4 in the benchmarks shown, maybe it's just because of the issue described in the following message:
http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html

Marcel

Floating point code on AMD64

[cimetmc]

It seems that certain types of 64 bit floating point code suffer from some stupid optimizations done in the GLIB header files. I think it is worthwhile reading the following message for people needing fastest possible floating point code on AMB64 processors:
http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html

Marcel

Reducing binary size

[tepples]

i wonder if we windows users could *finally* deliver executables as small as those made with the VC++ compiler.

Have you tried 1. compiling with gcc -Os to disable unnecessary unrolling and 2. stripping out debugging symbols at link time with gcc -s on builds on which you don't plan to use a symbolic debugger?

God, this gets old.

[stonecypher]

You know, I remember when someone did this to GCC 3, comparing against 2.9.5.

4.0.0 is a brand new compiler. Lots of techniques in it are brand new. Lots of tweaks and polish can be applied. If you actually take the time to compare 3.4 to 3.0, you'll find that the gap is bigger than 4.0 to 3.4. Furthermore, if you compare 2.9.5 to 3.0, you'll find 2.9.5 is better than 3.0 by a much wider margin than 3.4 is to 4.0.

This is a misunderstanding of the nature of progress. 4.0 is a brand new compiler with brand new internal behaviors. Lots of things are at the It Works stage, instead of the It's Efficient stage. You can't compare a 3-year polished compiler to a 3-week polished compiler; it's utter nonsense.

If you want to compare 4.0 to something, compare it to 3.0, or sit down.

Re:God, this gets old.

[ChaoticCoyote]

What part of (from my conclusion):

Keep an eye on 4.0. Like a baby, we won't really appreciate its value until it's matured a bit.

...didn't you understand?

I'm more than happy to let GCC 4.0 mature. People should, however, have some sense of what 4.0 means and implies, which is what I was trying to convey in my article.

Re:God, this gets old.

[stonecypher]

A nonsense article based on a false premise with a trailing admonition that hey, by the way, you might be wrong doesn't make the remainder worthwhile. What part of "keep an eye on 4.0" didn't I understand? None of it: in fact, what I just told you was that the part you've already done was the broken part. Your admonition is the only sensible thing about the article.

At all.

Re:God, this gets old.

[Anonymous Coward]

I hope you realize that replying to every comment that is critical of your article in such a trollish manner makes you appear to be petty and childish.

It's OK to be wrong sometimes, buddy. Take a break.

Linux 4.6.11.8

[kula.shinoda]

Linux 4.6.11.8

What happened to 2.6.11.8 - 4.6.11.7?

Have they added working support for the SB Live! Audigy LS soundcard yet?

Embedded, multithreaded and real time code

[dsplat]

Yup. Embedded stuff has to live by some different performance rules. Sometimes optimizing code that is only using 2% of your CPU cycles is exactly the right thing to do. Two words spring to mind immediately: interrupt handler.

Multithreaded code runs into the same issues for the same reason. When you are holding a lock, work fast. This generally has little to do with whether your CPU is fast enough for the overall throughput. It has to do with handling critical sections of code within particular timing windows so that you can get back to listening for the next input.

Re:Do the new models replace or confuse old ones?

[Ian Lance Taylor]

Sorry, my answer was ambiguous. gcc does already support the ColdFire in many variants. I was just using that as an example of why you might use the m68k backend, not as an example of work which needed to be done.

Moving code to a different class

[dsplat]

if you moved it from a big class to a little class you may have reduced the size of the stack that's allocated before calling the function.

Without seeing, and profiling, the code in question we probably won't ever know. The first possibility that occurred to me was that it reduced page faults by putting the function close to whatever was calling it. Either of us could be right. This is just another illustration of why programmer instincts are not a reliable guide to what needs optimizing. We're better at doing the optimizations rather than finding opportunities for them.

Re:Do the new models replace or confuse old ones?

[bani]

yes it does, but the support is poor. not only for coldfire but for 68k in general. gcc tends to make poor use of register-rich architectures. you can see this in eg powerpc assembly output. there is also no MAC/EMAC support in gcc afaik, so no autovectorization...

Keep a civil tongue in your head mate !

[Anonymous Coward]

For your information: C is s subset of C++, and floating point intensive code in C++ is treated no better than in C. Likewise for integer-intensive code.

Therefore: with respect to the floating preformance of GCC 4.0 (generally what matters most in technical and scientific work) this is an informative and valid test. Furthermore the fact that the author carefully states what benchmarks he runs allows you to scoff at him.

If you would like a test that measures how fast GCC can juggle dense forests of pointers ... feel free to carry out and publish your own test. Until then ... why not keep a civil tongue in your head?

Parent is incorrect!

[Anonymous Coward]

babies are free!

Re:Do the new models replace or confuse old ones?

[Ian Lance Taylor]

When it comes to gcc 4, I disagree. I think gcc does much better with register-rich architectures than with register-poor architectures. By modern standards, of course, m68k is not register rich (nor register poor)--it only has 16 registers, and they are not fully orthogonal in that some instructions require data registers and some require address registers.

I also think that the m68k backend does not include EMAC support. Do you want to contribute support?

"problem" with gcc 4.0

[Anonymous Coward]

Keep an eye on 4.0. Like a baby, we won't really appreciate its value until it's matured a bit.

A lot of people will probably get upset when their code which compiled just fine with 3.4.x doesn't compile with 4.0.0 anymore.

Question is, should they be upset at the compiler?

Recently, I found this thread on the reactos forums. It is about compiling reactos with gcc 4. Sure enough, there were problems. One thing that caught my eye is this:

Also a mountain of Warnings in the reactos code mainly to do with signed and unsigned. Yep people have been mixing them all over the place some files have 10-20 Warning each just to do with signed and unsigned.

Seems like a good opportunity to start checking code against 4.0.0 and fix them warnings before they get promoted to errors in a subsequent version...

Re:Do the new models replace or confuse old ones?

[bani]

the rockbox project are porting to iriver (cf5249) and have done some work getting gcc to properly support it. i know they have emac macros, dont know what it would take to get them working in the gcc backend.

Of Babies and Compilers

[ChaoticCoyote]

To keep down the noise, I've removed the comment about the value of babies. Sheesh. ;)

I appreciate the responses herein, even the annoying ones. ;) Frankly, I'd love to see people do much longer, in-depth reviews of FOSS projects, if only to spur attention to issues of quality.

For those folk who have opposing opinions to mine: Please feel free to publish your own comparison or review.

optimizing strlen

[Anonymous Coward]

Actually strlen() can be a hotspot, and I've helped optimize projects where strlen/strcmp were at the top of the cumulative time list.

However, optimizing strlen itself *is* pretty crazy. Much better to use a string class/struct where the length of the string is a field, so that the strlen equivalent is an inlined "return _len;".

Re:optimizing strlen

[swillden]

However, optimizing strlen itself *is* pretty crazy.

Especially since any decent compiler (including gcc, since way back when) will optimize strlen automatically, inlining it and implementing it very intelligently. If you're lucky, the compiler will manage to optimize your "improved" strlen down to exactly what it would have produce if you'd done nothing. If you're not so lucky... the resulting code will be worse.

Re:Points For Style

[Kupek]

It's a typo. Get over it. It's italicized because were I speaking that sentence outloud, I would have stressed that word.

changelog

[XO]

just cp the changelog from 2.x to 3.0...

What's New:
Broke virtually everything
Fixed nothing
Made it slower

Yay!

What I wanna know

[Anonymous Coward]

Are all the amd64 code optimization bugs fixed, or is this just another version of Beta-ware?

Re:Gentoo

[Anonymous Coward]

"I don't know about you, but if I want my maths (=mathematics) misspelled I'll ask an American." - Anonymous

a technological step forward?

[Anonymous Coward]

Version 4.0.0 is laying a foundation for the future, and should be seen as a technological step forward with new internal architectures and the addition of Fortran 95.

The addition of Fortran 95 seems more like a technological step ten years back.

4.0?

[Anonymous Coward]

4.0? Does that mean that 3.x is getting reliable enough to upgrade from 2.something?

Apparently not, as of linux-2.6.11.8, 2.95.x is stil recommended.

The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it should be used when you need absolute stability. You may use gcc 3.0.x instead if you wish, although it may cause problems. Later versions of gcc have not received much testing for Linux kernel compilation, and there are almost certainly bugs (mainly, but not exclusively, in the kernel) that will need to be fixed in order to use these compilers.

Re:4.0?

[cimetmc]

The recommended compiler for linux 2.6.x is the main compiler which was used when linux 2.6 was released. The linux developers don't want to officially switch compilers in mid term of a version because that would be a potential additional source of bugs. It does not necessarily mean that newer GCC version would be less good. It's just that it might produce code that would behave differently for whatever reason and it would make development more difficult.

The dicussion about recommended GCC versions of the Linux kernel regularly pops up on the kernel mailing list. For instance, you can see one such a discussion here:
http://groups-beta.google.com/group/linux.kernel/b rowse_frm/thread/c2da87604102e689/5d754728f97e5105

A much better indicator on GCC quality is to see what versions various Linux distributions actually use. For instance, if you take SuSE pro 9.3, it uses GCC 3.3.5.

Marcel

Thanks

[Paradox]

Thanks for the pointer. I actually do know about ATLAS and LAPACK. The reason I'm using the GSL is because of deployment ease. It's much harder to deploy fortran-based software than it is C-based software.

But it might be cool to distribute an ATLAS backend too.

GCC-3.3.6 snapshot is unbeatable!!!

[Anonymous Coward]

ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050427/g cc-3.3-20050427.tar.bz2 is unbeatable!!!

Better compile time, code size, run time, ... all because of flawlessy old software!!!.

open4free © : gcc -Wall -pipe -Os -fomit-frame-pointer -march=i686

Re:Well at least it isn't like the disaster of 2.9

[stry_cat]

Yeah that was in my early days, I almost didn't continue with Linux.

So what is the best?

I've got two boxen at home, one RH9 which is great. The other is FC3 which is like beta testing for their RHEL. At work I've got RHEL and it is really great. I just need something for home that doesn't cost $$ and allows more flexiability than Windows.

My results (GCC4, PPC)

[sorbits]

I have a 27 KLOC project which is a lot of modern C++ (as in templates, iterators, traits, smart pointers, generic algorithms a.s.o.) and not optimized for any particular compiler.

My crude results (on PPC) is: 25% smaller code, but twice as slow as GCC 3.3.

I haven't followed the GCC development so I don't know which state it's currently in or what's planned for the future. But I guess it'll only get better from here.

Re:My results (GCC4, PPC)

[cimetmc]

Unlike some people my think, the GCC developers are actually responsive to feedback if it is done in a helpful way. For instance, a performance degradation like reported by you is considered a bug by the GCC develoeprs, and what you should do in that case is submit a proper bug report, and the GCC develoeprs will look at it.

Marcel

Re:My results (GCC4, PPC)

[sorbits]

That's a good point, but I think I'll give them a little more time before I start submitting things like this as bugs -- I'm a developer myself, and generally don't like being told the obvious. I'm sure that the GCC developers are aware of the performance compared to 3.3.

I find this hard to believe myself, but I was told that GCC4 does no or little inlining, that would explain why my code is 25% smaller, and certainly why it's twice as slow (I'd think it'd be slower, since as mentioned, this is a lot of iterators, smart pointers and such), so if this is really true, then it's probably just a matter of time before they get this fixed

I should do some tests to verify the inline claim, just haven't had time yet! :)

Re:My results (GCC4, PPC)

[cimetmc]

As far as inlining is cencerned, the heuristics in GCC 4.0 have significantly changed, especially to fight astronomous compilation times in some pathological cases. However GCC 4.0 still has a lot of tuning knobs for inlining, and if you suspect inlining changes to be responsible for the performance difference, then playing with the inlining parameters might restore the old performance.

Marcel

Infinite improbability drive

[TFGeditor]

I get it, it's the same process whereby you get an infinite improbability drive, right?