Wild – A fast linker for Linux • Hacker News Board

Re: Wild – A fast linker for Linux

#101

Post by prmoustache » Fri, Jan 24, 2025, 9:53 PM UTC

easythrees wrote: post #74

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.

Wait a minute, it’s possible to relicense something from GPL to MIT?

Yes if you are the only developper and never received nor accepted external contributions or if you managed to get permission from every single person who contributed or replaced their code with your own.

Re: Wild – A fast linker for Linux

#102

Post by newman314 » Fri, Jan 24, 2025, 9:57 PM UTC

satvikpendem wrote: post #12

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

Re: Wild – A fast linker for Linux

#103

Post by KerrAvon » Fri, Jan 24, 2025, 9:59 PM UTC

I'm curious: what's the theory behind why this would be faster than mold in the non-incremental case? "Because Rust" is a fine explanation for a bunch of things, but doesn't explain expected performance benefits.

"Because there's low hanging concurrent fruit that Rust can help us get?" would be interesting but that's not explicitly stated or even implied.

Re: Wild – A fast linker for Linux

#104

Post by satvikpendem » Fri, Jan 24, 2025, 10:00 PM UTC

newman314 wrote: post #102

satvikpendem wrote: post #12

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

Then it'd be the /usr/bin/ld as I believe my solution was for before they moved the linker it seems.

Re: Wild – A fast linker for Linux

#105

Post by ajb » Fri, Jan 24, 2025, 10:05 PM UTC

wolfd wrote: post #88

ajb wrote: 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...

I’m not sure if you’re intending to leave a negative or positive remark, or just a brief history, but the fact that people are still managing to squeeze better performance into linkers is very encouraging to me.

Certainly no intention to be negative. Not having run the numbers, I don't know if the older ones got slower over time due to more features, or the new ones are squeezing out new performance gains. I guess it's also partly that the bigger codebases scaled up so much over this period, so that there are gains to be had that weren't interesting before.

Re: Wild – A fast linker for Linux

#106

Post by computably » Fri, Jan 24, 2025, 10:06 PM UTC

prmoustache wrote: post #101

easythrees wrote: post #74

Earlier quoted context omitted.

Wait a minute, it’s possible to relicense something from GPL to MIT?

Yes if you are the only developper and never received nor accepted external contributions or if you managed to get permission from every single person who contributed or replaced their code with your own.

> or if you managed to get permission from every single person who contributed

This makes it sound more difficult than it actually is (logistically); it's not uncommon for major projects to require contributors to sign a CLA before accepting PRs.

Re: Wild – A fast linker for Linux

#107

Post by sedatk » Fri, Jan 24, 2025, 10:12 PM UTC

shmerl wrote: post #78

sedatk wrote: post #72

Earlier quoted context omitted.

Because Rust compiler generates IR bytecode, not machine code.

That's the reason to use llvm as part of Rust compiler toolchain, not to use gcc or clang as linker manager?

You're right, @davidlattimore seems to have answered that.

Re: Wild – A fast linker for Linux

#108

Post by fuzztester » Fri, Jan 24, 2025, 10:19 PM UTC

Related, and a good one, though old:

The book Linkers and Loaders by John Levine.

Last book in the list here:

https://www.johnlevine.com/books.phtml

I had read it some years ago, and found it quite interesting.

It's a standard one in the field.

He has also written some other popular computer books (see link above - pun not intended, but noticed).

Re: Wild – A fast linker for Linux

#109

Post by sylware » Fri, Jan 24, 2025, 10:22 PM UTC

bmacho wrote: post #71

sylware wrote: post #66

The real issue is actually runtime ELF (and PE) which are obsolete on modern hardware architecture.

What do you mean by this?

ELF(COFF) should now be only an assembler output format on modern large hardware architecture.

On modern large hardware architecture, for executable files/dynamic libraries, ELF(PE[+]) has overkill complexity.

I am personnally using a executable file format of my own I do wrap into an "ELF capsule" on linux kernel. With position independent code, you kind of only need memory mapped segments (which dynamic libraries are in this very format). I have two very simple partial linkers I wrote in plain and simple C, one for risc-v assembly, one for x86_64 assembly, which allow me to link into such executable file some simple ELF object files (from binutils GAS).

There is no more centralized "ELF loader".

Of course, there are tradeoffs, 1 billion times worth it in regards of the accute simplicity of the format.

(I even have a little vm which allows me to interpret simple risc-v binaries on x86_64).

Re: Wild – A fast linker for Linux

#110

Post by mrighele » Fri, Jan 24, 2025, 10:31 PM UTC

computably wrote: post #106

prmoustache wrote: post #101

Earlier quoted context omitted.

Yes if you are the only developper and never received nor accepted external contributions or if you managed to get permission from every single person who contributed or replaced their code with your own.

> or if you managed to get permission from every single person who contributed This makes it sound more difficult than it actually is (logistically); it's not uncommon for major projects to require contributors to sign a CLA before accepting PRs.

That depends on how old and big is the project. For example Linux is "stuck" on GPL2 and even if they wanted to move to something else it wouldn't be feasible to get permission from all the people involved. Some contributors passed away making it even more difficult.