I’ve started building a number of large C and C++ packages regularly again (chromium, Linux kernel, gcc and others) so I thought it would be useful to get a sense of how fast the current compilers are relative to each other.

For my testcase I chose a library from the LLVM 2.8 toolchain.  I went with 2.8 as it’s the newest version I found that would compile with GCC (g++) 3.4.  I originally hoped to find a test that would build with all versions of g++ going back to 2.7, but unfortunately the C++ language specifications and compiler strictness have changed a lot in 20 years, so that wasn’t possible.  I compared built time using debug options (-O0 -g), standard build options (-O2 -g) and optimized build options (-O3 alone).  Time was measured in seconds.

Continue reading →

A rather common complaint about GCC, the GNU C/C++/Java/etc. compiler suite, is that each new release is slower than the last.  To verify this, I ran some tests building LLVM 2.8’s code-generation support library which seemed a fair benchmark given that it’s a sizable collection of C++ code.

As results below indicate, looking at all versions of g++ from 3.4 to the current development source (‘trunk’), there has been an overall slowdown between g++ 3.4 (released in 2004) and current trunk (to be released in earl 2013) at both the standard (-O2 -g) and optimized (-O3) build level, but in-between versions have fluctuated.  g++ 4.0 improved in almost all respects on g++ 3.4, and version 4.3 and 4.4 offered some speedups over their predecessors.  More recent g++ versions, starting with 4.5, have been steadily getting slower, by an amount varying between 5% and 20% with each release.

Continue reading →

Multiple core processors are the norm at this point, with four and now six cores being pretty much standard on desktop machines.  While the vast majority of software packages including pretty much all compilers are single-threaded, the build tool GNU Make has had the ability to use many threads for quite a while now with the -j flag.  While this requires makefiles to be written carefully to avoid implicit dependencies, the speedup can be quite significant.

As an example, here are the build-times for the clang C/C++ compiler and LLVM support libraries using from 1 to 10 threads.  The build system has a 4-core Intel Core i7 920 processor (2.6GHZ, Hyperthreading) which was state of the art about 3 years ago.

Continue reading →

GCC has been the de-facto standard compiler on Linux and most other platforms for compiling open-source software (e.g. apache, firefox, mysql etc.) for quite a while.  A standard complaint though is that the compiler has been getting steadily slower over time.  I’ve found this anecdotally true, and while for small projects it doesn’t really matter, when compiling Firefox takes upwards of an hour, it starts to be a more significant concern.

Continue reading →

One of my ongoing projects has been to build pretty much all major versions of GCC, mainly so that I can test the performance of the compilers over time.  For the last 7 or 8 versions, that’s not so hard – they build more or less okay on a current Ubuntu system.  Unfortunately, the further back you go, the more breakage there is.  For example, the C++ runtime in gcc 3.3 and 3.4 appears not to work with the current version of GNU libc.  And I can’t very well downgrade glibc without breaking, well, everything.

Happily, the combination of the chroot and debootstrap tools offers a rather painless alternative.

Continue reading →

Background

For a long time, the LLVM project used the various GCC front-ends with their compiler.  However, at the prompting of Apple who was looking for a faster compiler, as well as one unencumbered by the GPL 3 license, the clang project was begun in 2007.  Since then, clang has become a full featured C and C++ compiler. While installing the compiler on current versions of Linux isn’t quite the chore that GCC is, there are still a number of complications.  Below are my notes on installing the compiler on the  Ubuntu 12.04 (Precise) Linux distribution on a 64-bit (x86_64) machine.  Note that the compilers can still generate 32-bit code (using the -m32 switch).

Continue reading →

Back when I was first starting to use Linux, I made the mistake of attempt to upgrade my installation, package by package, to a newer release (I didn’t have a  CD burner at the time).  Unbeknownst to me, the newer distribution included a newer, incompatible version of the GNU C library (glibc), so when I upgraded the glibc package, every application that was dynamically linked against glibc, including the package manager itself, broke.  The system was hosed.

Continue reading →