Slashdot Mirror
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.'"
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"...software written in the C++ programming language should run faster--..."
Is this the programmer's way of saying it will run at some speed less than faster?
But will it compile C++ any faster? The difference between compile times of C and C++ files is staggering. Compiling Qt/KDE takes forever with gcc 3.x.
"GCC 4.0 also introduces a security feature called Mudflap, which adds extra features to the compiled program that check for a class of vulnerabilities called buffer overruns, Mitchell said. Mudflap slows a program's performance, so it's expected to be used chiefly in test versions, then switched off for finished products." - from the article
I really love this feature, it will probably cut down on a great deal of problems. My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.
More detailed information on the mudflap system can be found here.
It's pretty cool. You write a loop like this:
and the complier will handle the creation and syncronization of all the threads for you. Here's a OpenMP for GCC project on the FSF site. Looks like it's still in the "planning" state, though, so I'm guessing it's not in GCC 4.X.Problems are like gifts, it's better to give than to receive
Screenshots, screenshots! I need screenshots people!!!
And how many times will they break ABI, API and library compatability in THIS major release? Count stands at 4 for the 3 series, maybe higher.
The biggest challenge with Binary compatability across Linux distros is the GCC release (followed by the glibc releases, who live in the same ivory tower). I realize that things have to change, but I wish that they would not break compat between versions quite so often...
I'd really like to be able to take a binary between versions, and it just work.
This is one area where Sun rocks. Any binary from any solaris2 build will just work on any later version. With some libraries, you can go back to the SunOS days (4.1.4, 4.1.3UL, etc). That's 15 years or so.
Zapman
but the reason it takes forever to compile KDE lies in fact that it uses extensively the templates. While templates (a.k.a. generics) are a very useful language feature, they increase compile times. Including support for export template feature could help but only when anybody would use it in their code.
You can make an experiment and try compiling KDE with Intel C++ or Comeau C++ compilers, and see that not much can be gained comparing to GCC.
You can defy gravity... for a short time
I wish the compiler would output sane error messages on compiling code that uses a lot of templates (i.e STL). At least fixing it so that the line numbers are shown during debugging would be a huge improvement!
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
What does GCC have to do with this?
If you want something added to the standard, talk to the C++ standard committee. (Either the Library or the Evolution groups, in this case.) You'll find you're about the 10,000th person to ask for this. You'll find there's an extensive FAQ on this exact subject. You'll find that the committee is very keen on adapting large parts of Boost, as experience in the real world smooths the rough edges of Boost.
If you look a bit more, you'll find that some extensions have already been adopted (called "TR1") and are being shipped with GCC 4.0.
You'll also find that GCC does not get to determine what's in the standard. And -- speaking as one of the libstdc++ maintainers, although I'm largely too busy to do much myself these days -- GCC will not ship Boost. Or glibc. Or libAPR. Or OpenSSL. Or any of the other million very useful open source libraries out there, because that's not our job.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
If you're interested, here's a (long) discussion which makes reference to many of the things coming in the new GCC.
Game! - Where the stick is mightier than the sword!
We're working on the necessary infrastructure to associate the pragmas with the syntactic constructs they apply to. Actually parsing the OpenMP directives was already implemented - twice - but GCC does not support pragmas with a lexical context yet. This is needed for a bunch of C extensions, so we're working on that. This is probably GCC 4.1 material. After that, actually generating concurrent code from OpenMP pragmas is next.
(I'm especially excited by the possibility of random compiler incompatibilities!)
First, you are missing view of an ideaology among many open source projects which is to create a very powerful and optimized that does not bind itself, its users, or any other projects that want to build on top of it to any particular GUI. Most programs do this by running in extremely flexible commandline interfaces, allowing library interfaces, or just being a library for external programs to reference. You do have a point, however, that there is a lacking of a good IDEs in the linux community. I don't think any of us can deny the tremendous effect of an extremely good IDE (Eclipse for java for example). I think within the open source community one of the biggest threats they have to people just picking up linux and wanting to program is a lack of a good IDE. Honostly, when i'm programming in .NET on Visual Studio 2003, I feel like i'm in heaven. I only wish I could have the same type of luxury within linux (Especially with the MONO project!). But with all things, it takes contribution.
It's been my experience that they only have a lack of respect for incorrect code. If your legacy code is incorrectly-written, then you assumed the risk to begin with, says me. Write to the standard.
"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!)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)
We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.
Wanna know when this is gonna happen? Sooner, if you help.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
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. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Hands up, everybody who remembers when "g++" was a shell script!
...
Are you going to rob us? At first I thought that was your joke, but the more I think about it, the more I wonder if, being a part of the gcc team, you are inserting insidious code to look for credit card and bank account numbers on the disk during compiles and use steganography to embed them in executables; no one else would know about them, and all you'd need is a robot crawling download pages, looking for binaries with some magic code somewhere
The little bit of extra disk thrashing during the combined compile and search would never be noticed, and no one looking at compiled machine lanuage ever wonders why it is so odd looking. They just assume it's because of some new fangled optimization.
My god you are devious rascals!
Infuriate left and right
GCC is an incredibly versatile compiler, with frontends for C, C++, Java, Ada and Fortran provided with the basic install. 3rd party extensions include (but are probably not limited to) Pascal, D, PL/I(!!) and I'm pretty sure there are Cobol frontends, too.
They did drop CHILL (a telecoms language) which might have been useful, now that telecoms are taking Linux and Open Source very seriously. As nobody seems to have picked it up, dusted it off, and forward-ported it to modern GCCs, I think it's a safe bet that even those interested in computer arcana are terribly interested in CHILL.
OpenMP as been discussed on and off for ages, but another poster here has implied that design and development is underway. OpenMP is a hybrid parallel architecture, mixing compiler optimizations and libraries, but I'm not completely convinced by the approach. There are just too many ways to build parallel systems and therefore too many unknowns for a static compile to work well in the general case.
Finally, the sheer size and complexity of GCC makes bugs almost inevitable. It provides some bounds checking (via mudflap), and there are other validation and testing suites. It might be worth doing a thorough audit of GCC at this point, so that the 4.x series can concentrate on improvements and refinements.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
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.
"They that can give up high performance to obtain a little temporary security deserve neither performance nor security."
--not Benjamin Franklin
My other first post is car post.
No idea about MSVC, it doesn't build very good Linux binaries though anyways.
Game! - Where the stick is mightier than the sword!
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.
Some drink at the fountain of knowledge. Others just gargle.
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
It's a pretty far-fetched idea, but...
LLVM can be used as a GPL bypass. If this were to
become a problem, people would not feel as good
about contributing to gcc.
Well, that's how RMS thinks anyway. Never mind that
adding LLVM would enable some really neat stuff.
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...
I didn't go into details because this has been covered elsewhere, and I'm tired of discussing it myself. But I didn't realize I would be accused of "uninformed slander". So. A bit of background info first.
Inside the guts of the compiler, after the parser is done working over the syntax (for whatever language), what's left over is an internal representation, or IR. This is what all the optimizers look at, rearrange, throw out, add to, spin, fold, and mutilate.
(Up to 4.0, there was really only one thing in GCC that could be properly called an IR. Now, like most other nontrivial compilers, there's more than one. It doesn't change the political situation; any of them could play the part of "the IR" here.)
Once the optimizers are done transforming your impeccable code into something unrecognizable, the chip-specific backends change the IR into assembly code. (Or whatever they've been designed to produce.)
Each of these transformations throws away information. What started out as a smart array class with bounds checking becomes a simple user-defined aggregate, which becomes a series of sequential memory references, which eventually all get turned into PEEK and POKE operations. (Rename for your processor as appropriate, or look up that old joke about syntactic sugar.)
Now -- leaving out all the details -- it would be Really Really Useful if we could look at the PEEKs and POKEs of more than one .o at a time. Since the compiler only sees one .c/.cpp/.whatever at a time, it can only optimize one .o at a time. Unfortunately, typically the only program that sees The Big Picture is the linker, when it pulls together all the .o's. Some linkers can do some basic optimization, most of them are pretty stupid, but all of them are limited by the amount of information present in the .o files... which is nothing more than PEEK and POKE.
As you can imagine, trying to examine a pattern of PEEK and POKE and working out "oh, this started off as a smart array class with bounds checking, let's see how it's used across the entire program" is essentially impossible.
Okay, end of backstory.
The solution to all this is to not throw out all that useful abstract information. Instead of, or in addition to, writing out assembly code or machine code, we write out the IR instead. (Either to specialized ".ir" files, or maybe some kind of accumulating database, etc, etc; the SGI compiler actually writes out .o files containing its IR instead of machine code, so that the whole process is transparent to the user.) Later on, when the linker runs, it can see the IR of the entire program and do the same optimizations that the compiler did / would have done, but on a larger scale.
This is more or less what all whole-program optimizers do, including LLVM. (I think LLVM has the linker actually calling back into the compiler.)
The "problem" is that between the compiler running and the linker running, the IR is just sitting on the disk. Other tools could do whatever they want with it. RMS's fear is that a company would write a proprietary non-GPL tool to do all kinds of neat stuff to the IR before the linker sees it again. Since no GPL'ed compiler/linker pieces are involved, the proprietary tool never has to be given to the community. Company wins, community loses.
End of problem description. Begin personal opinionating.
It's a legitimate concern, but many of us feel that a) it's going to happen eventually, and b) we do all GCC users a disservice by crippling the tools merely to postpone an inevitable scenario. As usual, there's a wide range of opinions among the maintainers, but the general consensus is that keeping things the way they are is an untenable position.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)