What to expect from the new binutils linker

I’ve been following Ian Lance Taylor’s updates on the status of gold, the new binutils linker, for a while, so when he announced that he’d added it to the binutils tree, I decided to make a little time to try it out.

I have a fairly large C++ application handy, so I tried linking it on my dual core Thinkpad with 2GB of memory, running Fedora 8.

When I compile this application with debugging symbols enabled, it’s not exactly fast to link: it takes about a minute. Because the amount of data the linker has to chew through is impressively large, the actual time varies by up to 20% from one run to the next: all of those object files don’t fit into memory at once. This also has the unpleasant effect of paging out parts of apps I’m trying to use, such as Emacs and Firefox. Hmph.

In this situation, gold does indeed improve linking performance, bringing the linking time down to about 40 seconds. The poor laptop’s disk still spends a lot of this time grinding away due to the sheer volume of data, so once again the number isn’t very repeatable.

To eliminate the effect of memory pressure, I used “strip -g” to drop the debug information from the main app’s object files. (The libraries it links against still contain debug info, but they’re much smaller than the app itself.)

Stripping the object files speeds up the regular binutils linker by a factor of four, reducing linking time to 14 seconds. The laptop’s disk is no longer being touched. I can still edit text files after a link without big initial stutters. Whew!

When I switched to using gold as the linker, I was at first a little surprised to find that it actually works at all. This isn’t especially common for a complicated program that’s just been committed to a source tree. Better yet, it’s as fast as Ian claims: my app now links in 2.6 seconds, almost 5.4 times faster than with the old binutils linker!

When I ran “ld –help”, I noticed the tantalising options “–threads” and “–thread-count”, so I tried those. It turns out that thread support is not enabled by default: I reconfigured, rebuilt, and tried again. Running with “–thread-count 2″, the linking time drops slightly, to 2.3 seconds: that’s nearly 6.1 times faster than before.

Does the application actually work when linked by gold? Yes, so far with no signs of problems. It’s about 3% larger than the version produced by the old linker. I haven’t looked into why this might be.

Is gold ready for prime time? It’s not too far off. It doesn’t support the –build-id flag, which my copy of gcc 4.3 is convinced it wants (perhaps because I’m running Fedora). It doesn’t link the Linux kernel properly, because the kernel tortures the linker in twisted and innovative ways. Also, I have run into a few non-reproducible crashes when running in threaded mode, such as the following:

internal error in find_runnable_or_wait, at ../../gold/workqueue.cc:262

Overall, though, I’m very impressed, and I’m looking forward to the point where gold entirely supplants the existing binutils linker. I expect that won’t take too long, once Mozilla and KDE developers find out about the performance boost. Great work, Ian!