Red Hat Enterprise Linux 7 toolchain a major performance boost for C/C++ developers

Now that Red Hat Enterprise Linux 7 is publicly available, we thought RHEL application developers would be interested in seeing how the new C/C++ toolchain compares to the equivalent in Red Hat Enterprise Linux 6 in terms of raw performance. The numbers are pretty surprising so stay tuned. But first a little introduction to set the scene.

Red Hat Enterprise Linux 6 gcc

Red Hat Enterprise Linux 6 shipped in November 2010 with gcc-4.4. As with all major new version of Red Hat Enterprise Linux, we included a major release of gcc – in this case gcc-4.4, which was originally released in 2009. We use the exact same tools to build Red Hat Enterprise Linux as we include in the release, and we stand behind that toolchain with Red Hat’s service level agreement – far in excess of what you’ll have access to upstream. In short, we’ve got your back and will do our best to help with any bugs or issues you find as you develop your own applications. As users of Red Hat Developer Toolset will know, however, the emphasis in a Red Hat Enterprise Linux toolchain release is first and foremost on stability and reliability. We fix bugs and roll in new hardware enablement as we can without de-stabilizing the release, but enterprise quality is our primary goal.

gcc-4.8 in Red Hat Enterprise Linux 7 and Developer Toolset 2.x

The complementary product Red Hat Developer Toolset provides an alternative set of additional tools with an annual update cadence passing along the latest stable upstream gcc releases to our developers. You can read more about Red Hat Developer Toolset and watch a demo video here. Both Red Hat Developer Toolset 2.x and Red Hat Enterprise Linux 7 include gcc-4.8, which, until April 2014, was the latest major release of gcc upstream. So how does the newer gcc-4.8 release in those releases compare with the gcc-4.4 shipping today in Red Hat Enterprise Linux 6?

gcc-4.4 vs gcc-4.8

Red Hat toolchain engineer Vladimir Makarov dug into the relative performance of the two compilers using upstream releases and the SPEC CPU2000 performance benchmarks. The SPEC benchmarks are a well respected, standardized set of performance benchmarks which aim to test “real-life” situations. They are developed and maintained by the Standard Performance Evaluation Corporation, a non-profit organization. While we’re focusing on toolchain performance in this post, you should also take a look at this one, in which other SPEC benchmarks are used to measure Red Hat Enterprise Linux’s performance with highly resource-intensive and scalable workloads (executive summary: excellently!).

Vladimir’s comparison of gcc-4.4 and 4.8 used SPEC CPU2000 and aimed for peak performance, achieved by enabling not just optimization options but also new compiler features and processor support. Although the terminology is slightly inaccurate, for ease of reference we’ll call this “peak performance”.

Three versions of gcc were tested in this way: gcc-4.2.4, gcc-4.4.4, and gcc-4.8.2, and all were run on the exact same Intel Haswell hardware (3.4 GHz i5-4670) under the same load. Why are those particular versions of gcc significant? Well, for a variety of reasons, but when it comes to comparing Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 gcc performance, gcc-4.4.4 is the gcc version released in Red Hat Enterprise Linux 6 and gcc-4.8.2 is the gcc version in the Red Hat Enterprise Linux 7.

The results

So, after crunching the numbers, what do we find? Well, Red Hat Enterprise Linux 7’s gcc outperforms Red Hat Enterprise Linux 6’s gcc on SPEC CPU2000 by approximately 10%, with specific results varying between 32- and 64-bit code, and between integer and floating point benchmarks. To give these numbers some context, we’d typically expect to see around 1.5% improvement in gcc’s performance with each new annual release of gcc upstream. So, for the four years between gcc-4.4 and gcc-4.8, we’d therefore expect something in the region of 6% improvement. It’s testament to the hard work of the upstream community, of which Red Hat is a sizeable percentage, that almost double that number has been achieved.

Closing thoughts

So, in conclusion, both Developer Toolset users and Red Hat Enterprise Linux 7 application developers should expect to see a very healthy performance improvement in comparison with Red Hat Enterprise Linux 6’s toolchain. And that’s in addition to the new standards support and extensive new features.

No benchmark is perfect, because the most important benchmark for your particular application is your particular application. Nothing else quite captures the coding idioms, performance profile and hardware characteristics as well as your own applications running on your production servers. So the best way to see what Red Hat Enterprise Linux 7’s tools will do for your application is to try it. Just be sure to start with the options we used.

Let us know your conclusions – we’d love to hear from you.

SPEC® is a registered trademark of the Standard Performance
Evaluation Corporation (SPEC).

Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.



  1. Sorry, but i have to call “BS” on the chart in this post.

    At first glance (and in some respects that’s all that matters) it seems that the “major performance boost” is an increase of >= 100%, based on the graph which has lost the bottom 0.0-0.9 on the y-axis.

    Instead, it’s a respectable 7-15% increase, which is still “major”, but maybe less inarguably so.

    I’m sure you’re not intending to be misleading, but the chart seems a little weasely. Maybe it’s partially the constrained form factor of my phone, where the title and chart are easy to see and the text takes a good bit more effort.

    1. Thanks for pointing this out – it was entirely unintentional and just missed our reviews. LibreOffice apparently defaults to automatic axes and that set the y-axis to start from 0.9. I’ve just re-generated the graph with that feature turned off, and the updated graph should be visible immediately.

Leave a Reply