A Detailed Look At The Speed Advantages To LLVM's LLD Linker

[phoronix]

Phoronix: A Detailed Look At The Speed Advantages To LLVM's LLD Linker

LLVM's linker "LLD" continues The LLVM Linker "LLD" has slowly been gaining more ground as developers try it out as a drop-in replacement to the GNU system linkers. What turns on many developers to LLD is the often "lightning fast" performance compared to the GNU linkers, even the Gold linker...

http://www.phoronix.com/scan.php?page=news_item&px=LLD-Linker-Why-So-Fast

[tildearrow]

LLVM's linker "LLD" continues The LLVM Linker "LLD" has slowly been gaining more

Missing something?

[Michael]

Missing something?

Copy paste fail between edits, fixed up now. Thanks.

[brad0]

FreeBSD and OpenBSD have switched to LLD for the linker.

[hax0r]

Is there any improvement in runtime performance? No. Spending little extra time during linking process is non issue, majority of endusers don't compile their software. GNU/Linux desktop users would benefit from faster EFL binary startup and quicker shared .so library resolution. GCC still offers better compatibility, produces faster and much smaller binaries e.g in firefox case.

[cl333r]

GCC still offers better compatibility, produces faster and much smaller binaries e.g in firefox case.

Thanks for the link, insightful but I'm not sure I believe it because the author seems to be a GCC dev and heavily biased. I'm not into compilers so I can't judge, would be great if a LLVM dev commented on that.
Though being a C++ dev I totally like LLVM a lot better than g++.

[flower]

Is there any improvement in runtime performance? No. Spending little extra time during linking process is non issue, majority of endusers don't compile their software. GNU/Linux desktop users would benefit from faster EFL binary startup and quicker shared .so library resolution. GCC still offers better compatibility, produces faster and much smaller binaries e.g in firefox case.

imho binary size is a non issue. most of my ram and disk is not used by code segments.

faster startup times are nice to have.
faster binaries are more important though

[brad0]

Is there any improvement in runtime performance? No. Spending little extra time during linking process is non issue, majority of endusers don't compile their software. GNU/Linux desktop users would benefit from faster EFL binary startup and quicker shared .so library resolution. GCC still offers better compatibility, produces faster and much smaller binaries e.g in firefox case.

Still wouldn't use GCC. Not worth it for the marginal "better compatibility". Operating Systems and packages don't magically build themselves.

[cybertraveler]

Can Gentoo be configured to use it? Sounds like it would complement that OS perfectly.

[moltonel]

Is there any improvement in runtime performance? No. Spending little extra time during linking process is non issue, majority of endusers don't compile their software. GNU/Linux desktop users would benefit from faster EFL binary startup and quicker shared .so library resolution. GCC still offers better compatibility, produces faster and much smaller binaries e.g in firefox case.

There's pretty much no runtime performance difference to using Gnu's LD vs LLD vs Gold. Linking is orthogonal to compiling: you can compile with GCC and link with LLD, or any other combination. Compiling can be highly parallelized (using more cores and even more machines), but linking remains a singular step.

So go ahead and use the compiler that produces faster code for a particular codebase (that's sometimes GCC, sometimes LLVM, usually negligible) and use the faster linker to speed up your development process and therefore make the software better faster.

Linking Firefox takes around 15min with LLD on my machine, I don't even want to try linking with LD. Waiting for a build is a huge developer productivity killer.