GCC 4.0 Preview 684
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.'"
Re:I just want C++ programs to COMPILE faster (Score:2, Informative)
Re:OpenMP? (Score:5, Informative)
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 [nongnu.org] 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.Autovectorization (Score:5, Informative)
I'm so sorry, ... (Score:5, Informative)
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.
Re:boost, please ? (Score:3, Informative)
Re:GUI (Score:3, Informative)
Re:boost, please ? (Score:1, Informative)
Ten Boost libraries will be included in the C++ Standards Committee's upcoming C++ Standard Library Technical Report as a step toward becoming part of a future C++ Standard.
So yes. Eventually, anyway.
Re:GUI (Score:4, Informative)
Likewise, there are several IDEs that can nicely handle a C++ project which uses GCC. Eclipse [eclipse.org] is maybe the best example of these.
Besides, do you really want "Must have GUI to cope with compiler" on your resume? ;-)
Re:boost, please ? (Score:5, Informative)
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.
From what I've heard (Score:4, Informative)
If you're interested, here's a (long) discussion [gentoo.org] which makes reference to many of the things coming in the new GCC.
Compiler (Score:3, Informative)
Don't all compilers convert a program's source code into binary instructions?
Re:OpenMP? (Score:5, Informative)
Re:Shockingly better? (Score:4, Informative)
Actually, SSA trees probably count, which is new in GCC 4 (invented in the early 90's). Look here [apple.com], scroll down to "Power Through Builds" for a list of improvements from SSA trees.
Of course, this claim may be due to no longer doing something shockingly inefficient.
Latest Fedora-development has gcc 4.0 (Score:2, Informative)
gcc (GCC) 4.0.0 20050310 (Red Hat 4.0.0-0.33)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I've noticed it compiles a bit faster and the binaries are a bit bigger aswell.
Re:If GCC can compile C++, then... (Score:5, Informative)
Re:Mudflap (Score:2, Informative)
Re:C++ compiler (Score:5, Informative)
Yes, from here [apple.com]: "
Wrong. (Score:4, Informative)
Even the most cursory search of the GCC mailing list archives would disprove this.
Re:Autovectorization (Score:3, Informative)
Intel C compiler team (Score:4, Informative)
Re:Fortran??? (Score:1, Informative)
Re:Autovectorization (Score:1, Informative)
But don't you see that the multiple cores in Cell can be used like the extra MMX instructions?
The Cell's 8 cores can be used as independant proccessors, but for desktop-like situations they will probably not be.
The Cell has a extra 128 instructions added onto the normal PPC and Altivec ISO. Those extra 128 registers represent the extra 8 'vector' cpu 'cores' in the Cell.
So if GCC is able to 'autovectorize' the machine code to use as much as those extra 128 registers as possible (the extra 8 cores can run also integers and other datatypes, not just floating point) then code for some applications (games, multimedia) can be optimized very well to run on Cell.
Another clue if you looking into the funding and the technology (look for whitepapers in google) behind the autovectorization and related software technology in Gcc you'd see one name over and over and over again..
IBM
IBM
IBM
IBM
IBM...
So remember that Cell, while multicore, is not multicore in the same sense that it's SMP like Opterons will be.
Each Cell would be seen as one cpu (or realy 2 cpus since the Cell is SMT-capable), with the extra 'vector' cores seen as extensions like MMX/SSE/Altivec are.
Re:GUI (Score:3, Informative)
That's: g++ -o myapp file1.cpp file2.cpp file3.cpp
Ahem. (Score:5, Informative)
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 [gnu.org].
Re:Why not run it all the time? (Score:2, Informative)
So this is a nice debugging feature that might catch a few hard system bugs but I'm a bit concerned that the GCC folks are touting it as a security feature if it's rarely going to be used in production code.
Re:Mudflap (Score:2, Informative)
Eerily reminiscent of VAX/VMS's "/ARRAY_BOUNDS_CHECKS=ON" option, around 1985 this was. Admittedly, this was for Pascal or somesuch.
Cool thing for gcc nonetheless. Don't forget to check Boehm's Garbage Collector for C [hp.com] and/or Bruce Perens' Electric Fence [perens.com]
Re:I just want C++ programs to COMPILE faster (Score:4, Informative)
1) make (or some equiv). Yes, I said make.
GNU make accepts a -j parameter, to thread builds. Only really useful on hyperthreading or multiprocessor boxes, however. That said, if you use:
2) http://distcc.samba.org/ [samba.org]: distcc. You can distributedly compile your apps across other machines with a similar setup. Only really helpful if you have more then one box.
3) http://ccache.samba.org/ [samba.org]: ccache. This is a C/C++ compiler. Only really useful for iterative development, and if you're doing a lot of make clean/make, as it'll cache things that don't to be rebuilt.
Just some suggestions. Also, check out prelink, to prelink anything using shared libraries (trade space-savings into performance) and make startup code run faster in some cases.
Hope that helps!
++Informative? Pwetty pwease?
Re:C++ compiler (Score:5, Informative)
http://people.redhat.com/bkoz/benchmarks/
Doesn't look public though.
Re:Nitpicking (Score:2, Informative)
I just hope that GCC closes the gap with 4.0.
Performance on optimizations? (Score:5, Informative)
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.
Re:and how many times... (Score:4, Informative)
Re:Latest Fedora-development has gcc 4.0 (Score:3, Informative)
FC4 is not due for release for 4 months
If gcc development slips so does FC4
gcc 4 is ABI compatible with gcc 3.4
gcc 4 is ABI compatible with gcc 3.4
See above two statements.
This is Fedora releasing in June (possibly) not Red Hat's next release which will be a year and a half from now.
g95 is more mature than gfortran (Score:2, Informative)
If you just want a free Fortran 95 compiler use g95. Bugs reported to Andy Vaught are usually fixed quickly, and fresh Linux compiler binaries are posted almost daily. If you want to participate in the development of a Fortran 95 compiler, gfortran is more democratic.
Re:Not much. (Score:4, Informative)
Execution speed.
The gcc/g++ driver's purpose in life is to rip through the command line, figure out what other programs need to be run (compiler, assembler, linker, etc), fork them all off -- possibly in a loop, if you've passed more than one file on the command line -- and clean up afterwards.
"gcc -> real-work-programs" or "g++ -> real-work-programs" is a much faster executation path than "sh parser -> gcc -> real-work-programs", especially when your makefile is repeatedly invoking g++.
Maintainence is not especially difficult; g++ isn't really a seperate program. The difference between gcc and g++ is one or two extra .o files that get linked into the final executable. (Same for other language drivers that can't get by with plain "gcc", like the Java one.)
Re:I just want C++ programs to COMPILE faster (Score:5, Informative)
That's all you need to do. What's so hard? I use "using namespace std;" in the common include files of all of my home-built programs.
C++ is a different language. Not only is its syntax different, but the style of doing things is different. If you're expecting to not feel like it's an alien environment, you'll be sorely mistaken.
That doesn't mean it's bad; after a long time of resisting it for taste reasons, I started learning exactly *why* C++ does certain things, and how to put them to good use. And the differences can be staggering at times - templates are invaluable, destructors are invaluable, classed arrays (things like vectors instead of pointers) are invaluable, maps are invaluable, etc. These sort of things can knock out bugs you didn't even know were there, improve performance, drastically shorten, and clarify your code all at the same time. That's a rare combination of benefits in the programming world. You pay for it in compile time costs, but it's well worth it - especially when it comes to maintenance. You just have to accept that it's going to feel rather alien for a while, and during that time, you'll be asking yourself, "Why?".
BTW, Java 1.5 is becoming more and more like C++ every day. So, if you don't like the features of C++, you won't like them in modern Java.
Re:Screenshots! (Score:5, Informative)
Point-by-point response:
Re:Major Features Dropped From GCC 4.0 (Score:5, Informative)
Yeah, heavy on the "might".
Politics is what's preventing us from considering LLVM, let alone the long and torturous process of making the code work. 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.
Now, there are some of us (*waves hand*) who feel that RMS is a reactionary zealot in this respect, and would be more than happy to use the LLVM techniques, but we won't get into that.
Re:Performance on optimizations? (Score:2, Informative)
The list of other front ends for GCC [gnu.org] also include Cobol, Mercury, Modula-2, FLIM, Shakespeare, and GHDL. Note that all are in different states of development.
Re:Gcc killed fortran (Score:3, Informative)
Anyone who mistook g95 for F95 would indeed be right in concluding fortran was a dated useless language.
Dude, g95 [sourceforge.net] isn't yet completed. Why the hell would one expect it to be fully-functional? Got an axe to grind about the g95/gfortran fork?
My favorite parts of fortrans are that one cannot overflow a buffer
Rubbish, you can do just the same stupid things that you can with C. The difference is that Fortran can implement arrays without the need for pointers, and most Fortran compilers support decent (but very slow) bounds checking on these arrays.
RIP fortran95, killed by g95.
Again, this statement is misleading and meaningless. There are plenty of other mature Fortran 95 compilers on the market, and -- upon their completion -- g95 and gfortran will add to to the selection. How has g95 'killed' Fortran 95?
Re:I just want C++ programs to COMPILE faster (Score:5, Informative)
Const, operator overloading... all of it is great. Inheritance, too. There are so many things in C++ to help you keep your code small, easy to read, and clean. It feels a bit alien at first if you've been programming in C for a long time, but it's well worth it.
I have my faults with it, of course. I think streams were done rather poorly, for example. But overall, I'm glad I switched.
Re:Screenshots! (Score:4, Informative)
Re:Can anyone elaborate on this LLVM v. RMS issue? (Score:1, Informative)
Re:I just want C++ programs to COMPILE faster (Score:5, Informative)
They propogate down into every .cpp that includes your library's headers, whether or not the calling programmer wanted to import the entire std namespace.
Some programmers may have their own classes called map, or string, or list, or a dozen other things, and a single using statement buried in a nested .h can cause unanticipated namespace collisions.
In general, it's safest and most polite to refer to classes canonically in header files (std::string, etc), and keep the using statements in your implementation files.
Sources: "Accelerated C++" (Koenig, Moo); comp.lang.c++ (sample [tinyurl.com])
It's supposedly a GPL bypass (Score:3, Informative)
(like preprocessed, but more work having been done)
If gcc can convert C to LLVM, and LLVM to native,
then you could replace either half with something
proprietary. You could add a proprietary middle
step that optimized LLVM code.
Devphil is libstdc++ maintainer (Score:2, Informative)
Re:Major Features Dropped From GCC 4.0 (Score:3, Informative)
It's a shame, since I think the compile server has major potential - and not only in terms of improving compile speed. However, there is still a significant amount of work without a guaranteed payoff, and I guess Apple decided to spend its resources elsewhere. Also, various issues make it difficult for me to work much on the project.
Re:Mudflap (Score:4, Informative)
Re:I just want C++ programs to COMPILE faster (Score:1, Informative)
Re:I just want C++ programs to COMPILE faster (Score:2, Informative)
Hopefully, while one g++ process is writing out an object file to disk (waiting for disk io to complete) another can be using the CPU to parse or optimize.
Re:I just want C++ programs to COMPILE faster (Score:3, Informative)
For example, direct GCC to compile one top-level
#include "other-source-file-0.cpp"
#include "other-source-file-1.cpp"
#include "other-source-file-....cpp"
#include "other-source-file-673.cpp"
statements, one for each
This forces GCC to compile the whole program as a single unit, so it preprocesses the headers only once, and generates only a single object file.
This achieves approximately the same reductions in compile time as precompiled headers.
Come link time (which can be quite long even for a medium-sized project), instead of needing to combine hundreds of object files, the linker need only deal with one. On x86-Linux with GCC 3.4.x, at least, this accelerates the linking process, plus generates a much smaller and slightly faster binary. I assume that the slight acceleration in the generated code is due to the fact that compiling the entire project as one compilation unit has essentially the same cross-unit optimization benefits as link-time code generation.
Although this technique reduces from-scratch compile times considerably, it's of dubious value in most situations because:
a) Users compiling the software as part of an installation process might find it uncomfortable--or even impossible--to allow the compiler several hundred MB RAM.
b) The developer's changes in a typical edit-compile-test cycle are localized. This technique destroys the possibility of using previously compiled object files for those compilation units whose source code hasn't changed, since there's only one compilation unit for the entire project.
Re:sane error messages when using templates (Score:2, Informative)
I don't know precisely about STL, since I avoid relying on it, but you might check all include files. If you're on a unixy platform, try to get the list of all include files (via a "depend" like command) and check 'm all for line endings (the "file" command can be helpful).
Re:I just want C++ programs to COMPILE faster (Score:5, Informative)
That's not true. Building C is much quicker with Visual C++ than building C++. I know, I do it every day.
However, it is generally speaking true that gcc takes more time to compile than Visual C++ does.
No, here it is. (Score:5, Informative)
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.
C++ compilation speed (Score:3, Informative)
And if you are using templates, you are actually using a compile time language, which obviously will slow compilation down.
But they do claim [gnu.org] C++ compilation is much faster with 4.0:
Personally, I don't care much. Development seem to be restricted by link time, for a well organized project. And I always compile with full optimization.