Live data from Hacker News

Wild – A fast linker for Linux

github.com

131–140 of 222 posts

Re: Wild – A fast linker for Linux

#131
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…

> 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.

Instead of renaming and passing -B in, you can also modify the GCC «spec» file's «%linker» section to make it point to a linker of your choice, i.e.

  %linker:
  /scratch/bin/wild %{wild_options}
Linking options can be amended in the «%link_command» section.

It is possible to either modify the default «spec» file («gcc -dumpspecs») or pass your own along via «-specs=my-specs-file». I have found custom «spec» files to be very useful in the past.

The «spec» file format is documented at https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Re: Wild – A fast linker for Linux

#132
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 domi…

Yep in my case I have 11 * 450MB executables that take about 8 minutes to compile and link. But for small iterative programming cycles using the standard linker with g++, it takes about 30 seconds to link (If I remember correctly). I tried mold and shaved 25% of that time, which didn't seem worth the change overall; attempted wild a year ago but ran into issues, but will revisit at some point.

Re: Wild – A fast linker for Linux

#133

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.

Why does AGPL Vs MIT matter for a linker?

Re: Wild – A fast linker for Linux

#134

Earlier quoted context omitted.

OTOH even lld, fast but fairly slower than mold, is already incredibly faster than MS's linker even without the incrmeentality. Like, I'm routinely linking hundreds of megabytes in less than a second anyways, not sure incrementality is that much worth it

Not a rhetorical question: Could it be that part of the speed difference is due to the file system speed? I was shocked when I saw how much modern(ish) Windows file systems were slower than modern(ish) Linux ones.

it's usually windows defender and virus scanning that causes these massive slowdowns.

Re: Wild – A fast linker for Linux

#135
post #133

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.

Why does AGPL Vs MIT matter for a linker?

Corps don't want to have to release the source code for their internal forks. They could also potentially be sued for everything they link using it because the linked binaries could be "derivative works" according to a judge who doesn't know anything.

Re: Wild – A fast linker for Linux

#136
post #135
post #133

Earlier quoted context omitted.

Why does AGPL Vs MIT matter for a linker?

Corps don't want to have to release the source code for their internal forks. They could also potentially be sued for everything they link using it because the linked binaries could be "derivative works" according to a judge who doesn't know anything.

I think you should get new lawyers if this is their understanding of how software licenses work.

Re: Wild – A fast linker for Linux

#137

Earlier quoted context omitted.

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.

I'm waiting for 'linker-guy to weigh in, personally.

Re: Wild – A fast linker for Linux

#138
post #111

Earlier quoted context omitted.

Sure, for that 1% of the time.

...which takes these remaining 99% of a development time...

Surely your LTO bugs are not so easy to fix that they take less time to resolve than linking itself does.

Re: Wild – A fast linker for Linux

#139

I looked at this before, is it ready for production? I thought not based on the readme, so I'm still using mold. For those on macOS, Apple released a new linker about a year or two ago (which is why the mold author stopped working on their macOS version), and if you're using it with Rust, put this in your config.toml: [target.aarch64-apple-darwin] rustflags = [ "-C", "link-arg=-fuse-ld=/Applications/Xcode.app/Content…

Can you confirm that's still the right location for Sequioa? I have the command line tools installed and I only have /usr/bin/ld and /usr/bin/ld-classic

/usr/bin/ld will correctly invoke the right linker, it's a stub to look at your developer dir and reexec.

Re: Wild – A fast linker for Linux

#140
post #81

2008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...

Gold is slated for removal from binutils for version 2.44.0, so it's officially dead.

Where is the effort going now? lld?
Post reply on HN