21–30 of 43 posts
libstdc++ finally supports C++11's ! My team will be able to ditch boost regex once GCC 4.9 hits a stable version of Ubuntu. It is also nice to see more parity with Clang when it comes to diagnostics and ASan/UBSan.
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.
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.
> Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds. This is huge- you can now do this on a laptop
Seems like competition from clang led to some really practical improvements.
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?
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.…
> Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds. This is huge- you can now do this on a laptop
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.
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!
Earlier quoted context omitted.
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? edit: And both questions satisfactorily answered in the time it took me to perus…
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.
Earlier quoted context omitted.
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? edit: And both questions satisfactorily answered in the time it took me to perus…
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.
Earlier quoted context omitted.
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?
I am very curious too. Such drastic improvements often indicates something wrong before (either in design or implementation) that got fixed.
> 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.
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.