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.'"
"...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?
"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
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)
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.
It does take longer to compile C++. The solution to this is to keep Slashdot open in a browser. Back in the days before Slashdot, when compiling took even longer, programmers actually used to go ape-shit watching the compiler. We live in wonderful times.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
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)
Apparently. Found via google:
http://people.redhat.com/bkoz/benchmarks/
Doesn't look public though.
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)
And when they compile GCC 4.0 with GCC 4.0, it will be even fasterer!
1's and 0's should be free.
"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!
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.
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)
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).
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...