Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wild – A fast linker for Linux

github.com

Post reply on HN
Print view View original

91–100 of 222 posts

Re: Wild – A fast linker for Linux

#91

Post by pjmlp »

ComputerGuru wrote: post #13

There’s been a lot of interest in faster linkers spurred by the adoption and popularity of rust. Even modest statically linked rust binaries can take a couple of minutes in the link stage of compilation in release mode (using mold). It’s not a rust-specific issue but an amalgam of (usually) strictly static linking, advanced link-time optimizations enabled by llvm like LTO and bolt, and a general dissatisfaction with…

C++ can be rather faster to compile than Rust, because some compilers do have incremental compilation, and incremental linking.

Additionally, the acceptance of binary libraries across the C and C++ ecosystem, means that more often than not, you only need to care about compiling you own application, and not the world, every time you clone a repo, or switch development branch.

Re: Wild – A fast linker for Linux

#92

Post by shmerl »

davidlattimore wrote: post #85
shmerl wrote: post #58

That looks promising. In Rust to begin with and with the goal of being fast and support incremental linking. To use it with Rust, this can probbaly also work using gcc as linker driver. In project's .cargo/config.toml: [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-fuse-ld=wild"] Side note, but why does Rust need to plug into gcc or clang for that? Some missing functionality?

Unfortunately gcc doesn't accept arbitrary linkers via the `-fuse-ld=` flag. The only linkers it accepts are bfd, gold lld and mold. It is possible to use gcc to invoke wild as the linker, but currently to do that, you need to create a directory containing the wild linker and rename the binary (or a symlink) to "ld", then pass `-B/path/to/directory/containing/wild` to gcc. As for why Rust uses gcc or clang to invoke…

Ah, good to know, thanks!

May be it's worth filing a feature request for gcc to have parity with clang for arbitrary linkers?

Re: Wild – A fast linker for Linux

#93

Post by searealist »

bjourne wrote: post #86

What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.

Fast linkers are mostly useful in incremental compilation scenarios to cut down on the edit cycle.

Re: Wild – A fast linker for Linux

#94

Post by davidlattimore »

bjourne wrote: post #86

What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.

It sounds like you're building from scratch. In that case, the majority of the time will be spent compiling code, not linking. The case for fast linkers is strongest when doing iterative development. i.e. when making small changes to your code then rebuilding and running the result. With a small change, there's generally very little work for the compiler to do, but linking is still done from scratch, so tends to dominate.

Re: Wild – A fast linker for Linux

#95

Post by wolf550e »

bjourne wrote: post #86

What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.

The linker time is important when building something like Chrome, not small projects.

Re: Wild – A fast linker for Linux

#96

Post by dapperdrake »

kryptiskt wrote: post #50

What would be refreshing would be a C/C++ compiler that did away with the intermediate step of linking and built the whole program as a unit. LTO doesn't even have to be a thing if the compiler can see the entire program in the first place. It would still have to save some build products so that incremental builds are possible, but not as object files, the compiler would need metadata to know of the origin and depend…

SQLite3 just concatenation everything together into one compilation unit. So, more people have been using this than probably know about it.

https://sqlite.org/amalgamation.html

Re: Wild – A fast linker for Linux

#97

Post by dapperdrake »

almostgotcaught wrote: post #64
kryptiskt wrote: post #50

What would be refreshing would be a C/C++ compiler that did away with the intermediate step of linking and built the whole program as a unit. LTO doesn't even have to be a thing if the compiler can see the entire program in the first place. It would still have to save some build products so that incremental builds are possible, but not as object files, the compiler would need metadata to know of the origin and depend…

[flagged]

SQLite3 may be a counter-example:

https://sqlite.org/amalgamation.html

Re: Wild – A fast linker for Linux

#98

Post by paulddraper »

estebank wrote: post #44
pzmarzly wrote: post #19

Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.

Note that Mold has no interest in becoming incremental, so there is a big reason there for another linker to exist. I find it kind of embarrassing that MS' linker has been incremental by default for decades, yet there's no production ready incremental linker on Linux yet.

It has to be a candidate for the longest biggest gap in build tooling ever.

Re: Wild – A fast linker for Linux

#99

Post by paulddraper »

compiler-guy wrote: post #53
secondcoming wrote: post #27

Earlier quoted context omitted.

Maybe I'm holding it wrong, but mold isn't faster at all if you're using LTO, which you probably should be.

Mold will be faster than LLD even using LTO, but all of its benefits will be absolutely swamped by the LTO process, which is, more or less, recompiling the entire program from high-level LLVM-IR. That's extremely expensive and dwarfs any linking advantages. So the benefit will be barely noticable. As another comment points out, LTO should only be used when you need a binary optimized to within an inch of its life, su…

Username checks out.

And factual.

Re: Wild – A fast linker for Linux

#100

Post by paulddraper »

jcalvinowens wrote: post #80
Arelius wrote: post #60

Earlier quoted context omitted.

Yeah, if you're development process requires LTO you may be holding it wrong.... Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.

If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...

Sure, for that 1% of the time.
Post reply on HN