GCC 4.8 will feature a few improvements when it comes to LTO, a.k.a. Link-Time Optimization, but will this reflect in any greater performance for the resulting binaries?
Officially, the improvements to Link-Time Optimization in the forthcoming release of GCC 4.8.0 is rewriting the LTO partitioning for "better reliability and maintainability." The GCC change-log notes that several important bugs leading to link failures have been fixed. Being in a mood to do some new compiler benchmarks this weekend (and needing to test some new compiler-related features for the forthcoming release of Phoronix Test Suite 4.4-Forsand), I did a quick few on GCC 4.7 and 4.8 while testing LTO. My last article on the subject was the GCC 4.7 Link-Time Optimization Performance from August. If you're not familiar with LTO, read the aforelinked article for more details on what LTO means for GCC and how to exploit the potentially performance-enhancing feature.
Embedded in this posting are just a couple of the benchmark results where there was something to see while the system software/hardware details, system logs, and other test profile results can be found on OpenBenchmarking.org within 1302087-FO-GCC48LINK37. For GCC 4.8.0, the late January development snapshot was used.
BYTE's Dhrystone 2 test is one of the few cases where LTO has a marked performance difference. GCC 4.8 was slightly faster than GCC 4.7 on the Intel Core i7 "Ivy Bridge" system, but when enabling LTO it was of less advantage than under GCC 4.7.2.
Regardless of the impact on the performance of the resulting binary, the compilation time takes longer when enabling LTO due to the optimizations being done, well, at link-time.
LTO did cause the performance to regress for the widely-used Bullet Physics Engine.
In another result file (1302092-FO-GCC48LTO575) are a couple of more LTO benchmarks of the Core i7 system on the GCC 4.8.0 snapshot. With these extra benchmarks, the "-fwhole-program" compile-time switch was also tested beyond just "-flto" for enabling LTO. The "-fwhole-program" switch is to let the compiler "assume that the current compilation unit represents the whole program being compiled."
Find more compiler benchmarks at OpenBenchmarking.org.