GCC 4.0 Preview

Reducer2001 writes "News.com is running a story previewing GCC 4.0. A quote from the article says, '(included will be) technology to compile programs written in Fortran 95, an updated version of a decades-old programming language still popular for scientific and technical tasks, Henderson said. And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'"

Comments

I just want C++ programs to COMPILE faster

[drinkypoo]

Is it just me, or is compiling C++ code an order of magnitude slower than compiling C code? (exaggeration) I'm sure there's a very good reason why this is so, but it still doesn't make me happy.

Re:I just want C++ programs to COMPILE faster

[Anonymous Coward]

templates are invaluable, destructors are invaluable, classed arrays (things like vectors instead of pointers) are invaluable, maps are invaluable, etc.

I'll add a couple things that have been _very_ useful in my experience:

- the const keyword: if you want to make your codebase a whole lot safer, and compile AND run faster, const is great. (Yes I know it finally became part of the C language with the C99 standard...)

- the STL. Some love it, some hate it. For my old job (game programmer), it was invaluable. We made extensive use of certain containers, and the algorithms are great. Sure I learned how to write various sort routines in college but I don't even have to think about it when the STL already has an optimal version.

- operator overloading. Once again, some love it, some hate it. Game programmers deal with vector math and quaternions all the time, so this feature of C++ is put to good use. It makes the code read more like a math equation, instead of stuff like:

result = vector1.add(vector2);

There are probably more things that have slipped my mind but those are the ones that jumped out at me right away.

Re:I just want C++ programs to COMPILE faster

[captaineo]

This has more to do with the habits of C++ programmers rather than the language itself. If you take a random piece of C code and compile it as C++, it will probably take no more than 2-3x more time (the slowdown being due to a larger compiler binary, more sophisticated type-checking, etc). However what is often considered "good C++ programming style" involves inlining far more code than is the norm for C. (e.g. some STL implementations are entirely inline, whereas it would take a pretty crazy C programmer to implement hash tables and heaps inline). That's what blows up the compile time (and binary size).

The extra compile time buys you more inlining (which can be either good or bad for performance, depending on cache behavior) and also type-safe templates which are not acheivable in C (without ugly hacks).

Not much.

[devphil]

"gcc" will switch languages based on the filename extension. Many people compile C++ by calling "gcc".

"g++" suppresses that bit of logic and forces the language to be C++, which is useful if you have some C code that you want to be built as C++, or if you're feeding the C++ source from stdin (hence, no filename extension).

Linking C++, though, you want to use g++ instead of gcc, unless you really know what you're doing. The "gcc" driver doesn't know which libraries to pull in -- yes, this is something we'd like to change someday -- and the "g++" driver will correctly pull in libstdc++, libm, etc, etc, in the correct order for your linker and your system.

(Hands up, everybody who remembers when "g++" was a shell script!)

Re:C++ compiler

[Surt]

It claims the c++ front end is as much as 25% faster.

This is a troll, right?

[devphil]

The gcc team seem to have no respect for legacy code.

You've got to be fucking kidding me.

Have a look at the mailing list anytime somebody reports a bug, and the choice is between fixing the bug and changing the ABI. Watch the flamefests erupt.

(Watch them die down a few days later as one of the brilliant core maintainers manages to do both, with a command-line option to toggle between the default fixed version and the buggy old version.)

Wait a few months. See a new corner-case weird bug some in. Lather, rinse, repeat.

Incompatible syntax changes

Such as...?

All the ones I can think of were GCC extensions long before they were officially added to the languages. In fact, their presence in GCC actually influences their presence in an official language standard, because that's what the standards bodies do: standardize existing practice.

The troublesome part is when the syntax as added to the language standard differs from the extension that was originally put in GCC. Then we have to choose which once to support -- because supporting both is often not feasible -- knowing that whatever choice we make, slashdot is going to whinge about it. :-)

Major Features Dropped From GCC 4.0

[Qwavel]

At the GCC conference in Ottawa in the summer of 2003, there were two very interesting features presented that they said might make it into GCC 4.0.

- LLVM. Low Level Virtual Machine. This is a low level and generic pseudo code generator and virtual machine.
http://llvm.cs.uiuc.edu/
This sounded fabulous, and the project appears to be progressing well (it's at v1.4 now). If I understand correctly it is only politics that has kept it out of GCC 4. Can anyone shed more light on this?

- Compiler Server. Rather than invoking GCC for each TU you would run the GCC-Server once for the whole app and then feed it the TU's. This would make the compile process much faster and allow for whole program optimization.
This would have been nice but perhaps they found better ways to achieve the same thing.

Re:Major Features Dropped From GCC 4.0

[eviltypeguy]

The brutally short story is that GCC is operating under a certain restriction imposed by RMS since its inception, and LLVM -- or really, any good whole-program optimization technique -- would require us to violate that restriction.

Care to tell us what this oh so mysterious restriction is?

Yes, it's true

[Sycraft-fu]

Not sure what you tried but in most compiler benchmarks Intel ranges from "just as fast as the others" to "devistatingly faster". It sometimes generates code that's faster than hand optimised assembly designed to do the same thing. The Intel compiler even generates better code for Athlons than other compilers.

It gets even more devistating on Fortran. Seems Intel has like the only good Fortran compiler in the world. That's part of the reason their chips do so well on SPEC, the FP part is all fortran code and their compiler just rules at it.

If you Google around for compiler benchmarks you'll find a number of them, and virtually all show the Intel compiler dominating. One of the best, which I can't find a link for right now, was a test done by Toms Hardware. They did MPEG-4 encoding with the P4 and found that it blew. Intel figured something was wrong, got the source and recompiled the program (was compiled with VC++ 6.0). The P4 almost quadrupled in speed (and got even faster with the SSE optimised modes they added), and even the Athlons showed a near doubling in speed.

Re:Nitpicking

[Mad Merlin]

From what I've seen, ICC is still ahead of GCC, but Intel has actually been putting a fair bit of work into GCC, and this is showing in the newer releases of GCC (mostly with Intel processors however, who would have guessed?), mostly compile time related, but also some optimizations for runtime speed. I'd provide hard numbers, but I don't have ICC or the articles that mentioned such handy.

No idea about MSVC, it doesn't build very good Linux binaries though anyways.

Gcc killed fortran

[goombah99]

Gcc was what killed fortran. Gcc did not implement many fortran features forcing fortran programmers to use a pathetic subset of the language. For example in F77 they never implemented opening files read only (only open read-write) so you could never detect EOF's on pipes to fortran 77. But the real death knell for fortran was sung by g95 and its reduced language elements. Anyone who mistook g95 for F95 would indeed be right in concluding fortran was a dated useless language. Fortran95 does indeed have stucrtures, classes, pointers and allocatable memory contrary to widespread belief to the contrary due to g95. The irony is that fortan 2000 is actually a wonderful language for scientific programming in the coming age of multi-core processors. I would not write a wordprocessor in fortran but for sceintific programming its effieicient memory storage, implicit parallelism in the most basic elementes of the language language (for example for-loops that were allowed to iterate over their range out of order, and subroutines that declare which variables can have side effect) is perfect for the coming age of microprocessing. My favorite parts of fortrans are that one cannot overflow a buffer nor is it possible for a typo to compile. That last statment will elude understanding by most folks who never tried to write a line parser for fortran syntax but it's consequence is that hidden syntax errors that compile are impossible in fortran. (logic errors of course are possible in any language) one trivial example is you cant write = when you meant == or +=. Or the declaration of intent on calling arguments allows you to pass by reference without worrying that an array will be unintentionally modified. RIP fortran95, killed by g95.

Apple has been on the "leading" edge for a while

[CatOne]

OS X 10.2 shipped with GCC 3.1 I believe -- a while before it was released.

10.3 shipped with GCC 3.3, before 3.3 was released.

10.4 looks to continue the pattern. Apple takes a snapshot of GCC, forks it 6-9 months before the OS ships, tweaks/tunes/optimizes GCC, builds and ships with that version of the compiler, and then re-submits its changes, so future GCC builds (especially the PPC ones) get all the goodies.

And the compiler has had 6-9 months of QA from Apple, which is as good as the amount of credit you give their QA department ;-)

Re:Can anyone elaborate on this LLVM v. RMS issue?

[Anonymous Coward]

Over time, many companies have tried to make money off of portions of gcc without giving anything back to the community. For example, one of the Edison Group's C++ front-ends can be patched onto gcc, giving a "free" compiler for many platforms without giving a better C++ front-end to gcc. Currently, only an end user can patch gcc to work with that front-end. That restriction makes the product less attractive.

Because of this history, RMS does not want to make it easier for companies to take from gcc without giving back. LLVM would provide a clean interface between portions of gcc, and that clean interface could be so abused.

Remember that gcc has Objective-C support only because NeXT was forced to abide by the GNU GPL. Large portions of gcc were contributed by volunteers under the terms of the GNU GPL; their work was donated with the expectation that others' work would be made available. Many would see LLVM as a betrayal of that expectation. The next version of the GPL may address this issue...