4.8.0 was actually released in March 2013. GCC has been on a yearly major release schedule for several years now (since at least GCC 4.5.0 in 2010). This year 4.9.0 will be about a month late.
I use whatever compiler is defined in the makefile or called for in a README. Needless to say I do not really follow developments in either camp closely. I am curious what improvements are the result of "competition" from clang?
well, you could do it on a laptop before, you just needed a much beefier laptop. But that's really impressive, how did they cut the resource usage to a quarter of previous usage?
15 GB was presumably with LTO enabled, you could always build it on a fairly average laptop with it disabled. This is great news though, as LTO is pretty awesome.
For the uninitiated: LTO stands for
Link-time optimization and happens when the compiler
merges/links all separately-compiled object files
into one (executable or library).
Although it seems obvious that this might be a good idea,
why would it
1) use exorbitant amounts of memory; and
2) be "pretty awesome" instead of, say, mildly useful?
Link-time optimization is not a very descriptive term. It's usually called whole-program or interprocedural optimization. Link-time optimization is just how it has been implemented.
It uses a lot of memory because it requires keeping a representation of more or less the entire program in memory at one time, in a format which is amenable to analysis. It is not out of the ordinary for an optimizer's internal representation to be on the order of 1000x the size of the source code.
LTO, as the name implies, means that you do another optimization pass at link time. This enables lots of optimizations that don't work when you look at one module at a time.
Functions can be inlined across module boundaries, even when they're not declared inline. You can turn virtual functions into regular functions, if you know that the virtual function is never overridden, or if you can derive the exact type. You can change calling conventions for functions. You can do better escape and aliasing analysis. If a function is only called once, then you can probably optimize it a lot better because you know exactly how it will be called.
As with all optimizations, not all programs will see any significant benefit. Programs with heavy inner loops like physics simulators and graphics processors will not see much benefit, since the local optimizer works well enough. Programs like compilers, interpreters, and web browsers will see larger benefits. However, the benefits can be high—30% improvements in running time are not unheard of.
In short, LTO is a high-cost, high-benefit optimization.
Firefox recently (Trunk as of December) started using Unified Sources so builds are now typically 7-9 minutes on laptops now for non Windows platforms.
The things that caught my eye were both related to IBM hardware features.
Firstly, apparently IBM chips have hardware transactional memory now:
PowerPC / PowerPC64 / RS6000
GCC now supports Power ISA 2.07, which includes support
for Hardware Transactional Memory (HTM)
S/390, System z
Support for the Transactional Execution Facility
included with the IBM zEnterprise zEC12 processor has
been added.
That's pretty cool.
Also on the 390:
S/390, System z
The hotpatch features allows to prepare functions for
hotpatching. A certain amount of bytes is reserved
before the function entry label plus a NOP is inserted
at its very beginning to implement a backward jump when
applying a patch. The feature can either be enabled via
command line option -mhotpatch for a compilation unit
or can be enabled per function using the hotpatch
attribute.
I guess if you're doing high availability the mainframe way, you don't get to restart your apps to patch them. That's terrifying, but again, pretty cool.
The problem isn't bounds-checking, the problem is that most of the _s() functions that deal with bounds-checking already have pre-C11 equivalents that check boundaries.
I also disagree with some of the interface choices, for example when strlcpy() fails it tells you how many characters you needed, not simply "error" as in strcpy_s. Also the use case for memcpy_s() is extremely limited. It just seems like the _s() functions were rushed and stuck in there without regard for what makes sense.
42 comments
[ 2.1 ms ] story [ 88.6 ms ] threadIt is also nice to see more parity with Clang when it comes to diagnostics and ASan/UBSan.
I don't personally notice a change though, IMHO releases have been fairly consistently released since the 4.0 timeframe.
> As of this time no releases of GCC 4.9 have yet been made.
This is huge- you can now do this on a laptop
> Early removal of virtual methods reduces the size of object files and improves link-time memory usage and compile time.
> Function bodies are now loaded on-demand and released early improving overall memory usage at link time.
Although it seems obvious that this might be a good idea, why would it
1) use exorbitant amounts of memory; and
2) be "pretty awesome" instead of, say, mildly useful?
edit: And both questions satisfactorily answered in the time it took me to peruse the preamble of https://en.wikipedia.org/wiki/Interprocedural_optimization
Thank you!
It uses a lot of memory because it requires keeping a representation of more or less the entire program in memory at one time, in a format which is amenable to analysis. It is not out of the ordinary for an optimizer's internal representation to be on the order of 1000x the size of the source code.
Functions can be inlined across module boundaries, even when they're not declared inline. You can turn virtual functions into regular functions, if you know that the virtual function is never overridden, or if you can derive the exact type. You can change calling conventions for functions. You can do better escape and aliasing analysis. If a function is only called once, then you can probably optimize it a lot better because you know exactly how it will be called.
As with all optimizations, not all programs will see any significant benefit. Programs with heavy inner loops like physics simulators and graphics processors will not see much benefit, since the local optimizer works well enough. Programs like compilers, interpreters, and web browsers will see larger benefits. However, the benefits can be high—30% improvements in running time are not unheard of.
In short, LTO is a high-cost, high-benefit optimization.
Firstly, apparently IBM chips have hardware transactional memory now:
That's pretty cool.Also on the 390:
I guess if you're doing high availability the mainframe way, you don't get to restart your apps to patch them. That's terrifying, but again, pretty cool.https://www-950.ibm.com/events/wwe/grp/grp030.nsf/vLookupPDF...
I wonder if anyone is working to standardize something like this? It would be way more useful than all those _s() functions they added to C11.
I also disagree with some of the interface choices, for example when strlcpy() fails it tells you how many characters you needed, not simply "error" as in strcpy_s. Also the use case for memcpy_s() is extremely limited. It just seems like the _s() functions were rushed and stuck in there without regard for what makes sense.