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.'"
What I'd like to see is features like OpenMP for thread-level parallalism.
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.'"
Can we get Boost in standard library please ?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Does anyone have a LiveCD of this stuff? ;-)
echo "getuid(){return 0;}" > e.c; gcc -shared -o e.so e.c; LD_PRELOAD=./e.so sh
My guess is that they are using f2c (translating fortran to C first, then compiling), rather than integrating and updating g77. I don't expect this to match most native Fortran compilers for efficiency.
Actually, MS are pretty good at that as well.
You can still run software from 1981 on windows XP.
Take a look for yourselves (those in Windows) here
liqbase
That GCC is the staple in the embedded world. They could've mentioned that most probably it is the compiler used for the proverbias Internet toaster, or maybe even something sexier, like Formula-1 engine-tuning app... ;-) Apparently the article is written to educate the "general public", would be nice to put this little tidbit into their minds..
Paul B.
"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)
You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...
Can you run C++ applications compiled on Solaris 2 on any later version?
Compatibility is where Sun rocks, and it's also the rock that Sun is tied to. Most of the things that people hate about Solaris are kept that way because of their commitment to backwards compatibility. It becomes difficult to make signifigant changes if you focus on compatibility the way they do.
Linux and other OSS tools like GCC have advanced quickly partly because they have always been able to rewrite just about anything if they need to. Historically people were used to it, or okay with it. I wouldn't be suprised if at some point Red Hat and other Enterprise vendors forked a stable-ABI version of GCC, glibc, and Linux, because in larger environments backwards compatibility is very important.
It claims the c++ front end is as much as 25% faster.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
YES this is a huge problem. More than half of my Linux troubleshooting time can be traced back to version skew issues in either GCC or GLIBC. (libstdc++ changes, pthreads changes, exception handling changes, etc...)
Now that the C++ ABI is standardized, there is NO excuse for not having backwards- and forwards- compatibility for ordinary C and C++ executables linked against glibc.
The Linux kernel v2 ABI has been mostly backwards- and forwards-compatible since its first release. And Linux kernel guts change a lot more often than the C/C++ standards!
Autovectorization is a feature pushed by Apple. Since their AltiVec isn't being exploited like it *can* be, they've gotta push it into the compiler to give themselves a speed boost on G4/G5 (and rightfully so).
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.
I'll agree with you on this much: C+Mudflap is not the way to fix buffer overrun problems. The problem isn't that runtime safety is costly--it isn't--the problem is that adding runtime safety to the C programming language post hoc is costly because of C's screwed up pointer semantics. That's why Mudflap costs you a factor of 3-5 in terms of performance on benchmarks, when runtime safety in another language really should only cost you a few percent overhead at most.
Mudflap will probably not be used much for testing (people already have good tools for that they don't use) and it has too much overhead for most production use. The biggest thing Mudflap will do is perpetuate the myth that runtime safety is costly.
Anyone know when 4.0 will be ready for the distros?
3 monts? 6 months? a year ? forever?
.\.\att Clare
Unless things have changed recently, their front end is derived from gcc 2.96 (which, as most of you know, does not actually exist), and their backend is the Pro64/Open64 Itanium compiler retargeted to AMD64. And Pro64 is itself mostly SGI's MIPSPro retargeted to Itanium. The PathScale team leader is also the former SGI MIPSPro compiler team leader (Fred Chow). MIPSPro rocks, and PathScale is also pretty good. The best part is that the compiler is GPL'ed (but only v2, and with a patent infringement clause that actually violates the GPL itself *sigh*),
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)
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.
No idea about MSVC, it doesn't build very good Linux binaries though anyways.
Game! - Where the stick is mightier than the sword!
But will it compile C++ any faster?
I don't care if it compiles any faster, just as long as it compiles correctly. We were in the middle of a port of a major system to Linux recently, and the sysadmins decided we really need to install some patches. I shoulda' known better. I shoulda' said no.
They applied the Red Hat AS patches (which included patches to gcc) on the target machine, and suddenly newly compiled programs that had been working for years had memory overwrite problems. Strings and char arrays would contain things that should be in adjacent memory. The most obvious difference was the newly compiled code was much smaller than that produced by the unpatched gcc.
Luckily, we had another Red Hat AS machine which had not been patched, and I moved all the development work there. Then I promised the admins that I'd go postal if they touched gcc on that box. So far, so good, but I'd really appreciate it if the gcc guys would get it right before releasing stuff. One of the promised results of the above mentioned patch was a significant reduction in size. They got that part right at least.
SSA is an interesting representation to do optimizations on. Each "variable" is only assigned to from one static place in the program, making use-def chains easier to reason about. SSAPRE (Partial-Redundancy Elimination) is one of the most general optimizations, and has some big advantages (and some disadvantages) when compared to the old-style bit-vector PREs. One big advantage is you don't have to implement different local and global versions of your PRE to get decent performance.
Some languages can be parsed directly into SSA form fairly efficiently; however, most compilers will probably do a pass to convert their own parse tree format into SSA so they can optimize in SSA form. They might have to convert it back afterwards though. I think the first versions of GCC to do optimizations on an SSA form used to convert back and forth a few times.
It would be nice to see a mainstream compiler that does ALL its optimizations in SSA form (and no, the SGI compiler doesn't count)..
I suggest you try KDevelop before you go spreading lies about the non-existance of a good IDE for Linux.
And no, KDevelop is not only for making KDE programs
Is it just me, or is this the first "we will make it easy to program the Cell" step that Sony and IBM were promising?
Could be, but auto-vectorization will help not only Altivec enabled architectures (PowerPC G4, PPC970 G5, Cell), but it should also help x86 architectures as well, since SSE, SSE2, and SSE3 are Intel's version of vectorization, or essentially applying the same mathematical operation to many bytes of data at the same time. I think all modern architectures should see a speed increase, especially with multimedia type applications like video encoding/decoding/transcoding.
"When the president does it, that means it's not illegal." - Richard M. Nixon
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.
Working for a company that makes engine tuning products (Diablosport) I can say we sure do use GCC for quite a few of our products. Several different versions, but no 4.0 yet.
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
Is there anyone who knows what this LLVM issue is about? Anyone out there who is not just ranting incoherently about RMS?
Peace, or Not?
>> but Intel has actually been putting a fair bit of work into GCC
Bollocks. They only wrote some stuff to support IA64 because they were desperate and no-one else would.
And if you statically link against libc on, I suspect, at least some other UN*Xes (Solaris being one of them), you'd better be prepared to handle the consequences as well. The same, I suspect, applies if you statically link against the kernel32/gdi32/user32 libraries on Windows, if you even can do so.
Thus, it's not even clear that this (problems with installing completely-statically-linked binaries on OS versions other than the one on which it's built) is any worse than it is on Solaris or Windows, except for the "this week's version of glibc" problem. That would be the real problem, although if the binary requires this week's version of glibc because it was written for this week's version of glibc and uses functionality of this week's version of glibc, then, well, if you choose to do that, be prepared to handle the consequences....
(Yes, this means that making system developers' lives better by making the lives of some application developers harder, well, makes the lives of some application developers, such as the ones who want to use the latest shiniest APIs but still deliver their applications on systems lacking those APIs, harder. So it goes....)
And when they compile GCC 4.0 with GCC 4.0, it will be even fasterer!
Well, that's exactly how GCC is built. It would use the existing compiler you already have on your system to build a portion of GCC enough to compile/build the version of GCC you're attempting to build.
And it's absolutely horrible for any kind of C++ development. Look at Boost's C++ regression test suite results for gcc on Darwin - they are discraceful! The fact that they are branching in the middle of Stage 1 or early in Stage 2 has meant that they have a compiler that's about as bad as the infamous RedHat 2.96 series, only Apple, Inc puts out bugfixes even more rarely.
Its so bad, that I don't even use Apple's GCC for any C++ development; I always start by building a GCC/G++ from FSF's released codebase.
While I agree that C's golden age has come and gone, it shouldn't be relegated to the dust-bin of history yet.
There are many places where C is still used. There are many API's that are still in C. There's plenty of embedded systems programming that is done in C. So on and so forth. It has it's uses just like fortran has it's uses (and that's a rather ugly language IMHO).
A couple of years ago I was using C for embedded systems, due to the fact that the overhead incurred by C++ was just too large.
I still prefer C++ to the newer languages, along with the occasional assembler block for super critical performance code.
The newer languages certainly take a considerable amount of work out of the process (which I really like), but all those features come at a cost. And for those projects where the costs outweigh the benefits, "unsafe languages" will still be used.
I'd like one of the newer languages to have the power of assembly/C/C++ while still maintaining all their grace of memory saftey and management.
They're getting better, but they're not quite there yet.
~X~
~X~
printf("%d\n", ({for(i=2;i14;i++);i;}) );
My only concern is that some developers will think turning it off for releases is OK. Anyone who thinks that any real-world software project is a "finished product" is deluding himself. It reminds me of a quote I read somewhere, which said basically, "Turning off assertions to ship is like practicing on the ground with a parachute and not wearing it when you jump out of a plane."
Jeremy
Looking for a Python IRC bot?
Many modern filesystems use something called delayed allocation, so (eg, temp) files that are written and deleted shortly after, are removed from the write queue, and never actually make it to disk. I think I recall reading it coming to reiserfs a few years back. So the effect is that /tmp already is mounted in ram.
-2A
The revolution will not be televised... but it will have a page on Wikipedia
It's the same reason that RMS avoided adding dynamic linking support (for example to be able to add elisp wrappers around C libraries) to GNU Emacs, whereas this apparently exists in XEmacs.