GCC 4.9 Coming With Big New Features 181
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."
Re:A big improvement indeed (Score:3, Interesting)
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.
Re:Looks like they are porting Clang features... (Score:3, Interesting)
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.
Finish C++11 support first? (Score:5, Interesting)
Re:A big improvement indeed (Score:5, Interesting)
Re:Looks like they are porting Clang features... (Score:2, Interesting)
The 2-clause BSD license (which is the one used nowadays) is 7 lines of natural English (excluding the disclaimer) and people still can't understand it...
You can't take BSD code and change it's license.
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
IIRC a Linux dev though it was possible and did so with an OpenBSD piece of code. Some OpenBSD devs complained and the license was reverted to the original one. End of the "shitstorm."
Re:A big improvement indeed (Score:3, Interesting)
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.
Re:GCJ vs. JIT (Score:2, Interesting)
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.
Re:A big improvement indeed (Score:4, Interesting)
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.
Re:GCJ vs. JIT (Score:4, Interesting)
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.
Thank you, Clang (Score:5, Interesting)
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.
Re:GCJ vs. JIT (Score:4, Interesting)
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).