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: [...] we gave up on Java.
Well, actually it's the other way around: Java gave up on them - meaning that actual development of GCJ moved from GCC to OpenJDK.
Not that i understand what it means for GCC, but i understand that it does not mean much for Java.
Yep. They're also stealing OMP4.0 from Clang (which got OMP3.1 just a month or so ago, while GCC had it since 4.7) and Cilk (which is not in Clang at all, though people are working on 3rd party extension)
The whole post really reads quite trollish / alternatively Clang has hired black PR department.
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.
No, it is not. But GCJ Java-to-native compiling didn't result in particularly fast Java code. That's one of the major reasons developers and enterprises ignored GCJ in the first place.
Frankly I neither know nor care if your perception is that you have spent a lot of time cleaning up after security bugs, but the fact that you don't understood what my attitude is makes it fairly implausible.
For one thing, a lot of shops do not permit a drop into naked API calls, and areas of concern are often abstracted out. And even if they a developer and tests should be checking the documentation for that API. But that's all irrelevant. My point was that this is mainly useful on programs that already have flaws that should not be waiting either for Your Highness or gcc 4.9 to percolate into all of the used OSs.
If a bleeding edge compiler release is relevant to your security NOW you have problems.
No one programs anymore. All we do is link together pre-built libraries and frameworks and wrap it all in XML. Not sure who actually codes those libraries or where they come from, but the prevailing theory is that once a year the senior developers hike to the top of Mount Olympus and wrestle them away from the gods.
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).