Slashdot Mirror
GCC 4.9 Coming With Big New Features
jones_supa writes "When GCC 4.9 is released in 2014 it will be coming in hot on new features with a large assortment of improvements and new functionality for the open-source compiler. Phoronix provides a recap of some of the really great features of this next major compiler release from the Free Software Foundation. For a quick list: OpenMP 4.0, Intel Cilk Plus multi-threading support, Intel Bay Trail and Silvermont support, NDS32 port, Undefined Behavior Sanitizer, Address Sanitizer, ADA and Fortran updates, improved C11 / C++11 / C++14, better x86 intrinsics, refined diagnostics output. Bubbling under are still: Bulldozer 4 / Excavator support, OpenACC, JIT compiler, disabling Java by default."
New in this release: lots of stuff most people don't care about, some minor improvements and oh yeah we gave up on Java.
"Ada" is the name of a person, and the language.
"ADA" is the Americans with Disabilities Act, or the American Dental Association.
Sheesh, evil *and* a jerk. -- Jade
For God's sake, that's *THIRTEEN* (13) links to Phoronix!
Pointing to a couple of ML threads or to the 4.9 changelog would've been more than enough. http://gcc.gnu.org/gcc-4.9/changes.html
The whole article really reads quite fanboyish / alternatively GCC has hired a marketing department. But it looks really lame when you talk about exiting new features, and you just copied what Clang had before.
2014 is just a month and a half away, and you can compile 4.9 now from the dev branch of their subversion tree.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
But then how would Googlebot know that Phoronix is really great and popular and they should rank it higher in searches?
I see from the status page the Regex support is still not complete, part of the C++11 standard. It would be nice if support for this standard could be completed before starting on C++14.
finally
C++0x does not have "finally".
You'll have to implement it yourself, e.g. using a destructor.
See for example: http://codereview.stackexchange.com/questions/2864/an-implementation-of-finally-in-c0x
If Pandora's box is destined to be opened, *I* want to be the one to open it.
It's funny, but out of context. See: Jeff Atwood, “Regular Expressions: Now You Have Two Problems” June 27, 2008, http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html
- David A. Wheeler (see my Secure Programming HOWTO)
Please edit and re-submit.
putting the 'B' in LGBTQ+
1) "A good JIT actually performs very well compared" in theory. FTFY. We're about XX years before JIT'd languages can _reliably_ be as performant as C code in general application.
2) A full-blown JIT without garbage collection is actually pretty hard, so in practical sense you can't have JIT without a garbage collector. The JIT needs to understand the memory model and manipulate object lifetimes in a generic manner unrelated to the contextual semantics of the application, and the only practical way to do this is with a GC. So it's a little disingenuous to say that Java is slow because of GC. Without GC it wouldn't be JIT'd to begin with.
3) Array bounds checking isn't that big of a deal, nor is NULL checking. All good C code does it just as much Java does it. And this is one area where in practice JIT'd applications are reliably good at optimizing where it matters.
4) C applications don't usually copy by value, either, for compound objects. C++ used to do it a ton, but it was slow as heck, which is why recent changes regarding the move constructor were so important.
Ultimately, Java is slower and more of a resource hog because of limitations in the state-of-the-art. Yes, a _ton_ of genius has been put into making Java (and JavaScript, for that matter) incredibly fast. But at the end of the day it's easy to write well written C code which will blow well written Java code out of the water.
But it's all relative. Java is still within an order of magnitude of the performance of C, so it's all kind of pointless, anyhow. No need to be apologist about it. I use C principally, but also Lua and Perl. Lua uses a mark+sweep GC, and so just like Java there you have to be careful about stalling. Perl still uses reference counting, which is actually really helpful in many scenarios, although Perl itself is dog slow compared to Lua, let alone LuaJIT, Java, or C.
1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.
2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?
3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.
4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.
Mostly I agree with your points. Especially that Perl is dog slow.
Clang has really become a boon to open source compiler development. Unlike the open source *BSD operating systems, which are too far behind the GPL operating systems in many measures (not all), Clang has really electrified the compiler scene.
I see nothing but good things coming from this in near future.
And in such a rapidly evolving area as compiler development, having a *BSD license does not really hurt either. It's not like the *compiler* is likely to get put into some device with proprietary modifications.
I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?
Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no. A number of machine emulators (CPU->CPU, see apple Rosetta) perform dynamic translation, and in a number of cases pretty advanced optimization. There have also been a number of native dynamic translators for a given machine architecture see (http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html) for one example. There are also strange hybrids like the Intel Profile Guided Optimizations, where the feedback from a particular run is used to statically recompile the code. This effectively removes the profile/recompile overhead from an application at the expense of the fact that its now statically optimized for a particular kind of dataset.
But, you ask why isn't a JIT part of most compiler packages if it gives you all these advantages. And the answer is three fold. First OOO CPU's kill the majority of the advantage that projects like dynamo found. Secondly, the overhead of the dynamic translation monitoring/recompile is often greater than the performance gain. And finally, the JIT advantages are often isolated to small hot pieces of code (compared with optimizing an application that is hundreds of MB of code). Applications with small performance critical functions are often hand optimized in C/C++ languages in ways that cannot be done by simple dynamic optimization and often yield functions that execute at the maximum a particular piece of hardware is capable of (say limited by memory bandwidth, functional unit throughput, etc).