←back to thread

Wild – A fast linker for Linux

(github.com)
383 points hkalbasi | 3 comments | 24 Jan 25 16:25 UTC | HN request time: 0.001s | source
Show context
throwaway106382 ◴[24 Jan 25 16:43 UTC] No.42814864[source]▶
> Mold is already very fast, however it doesn't do incremental linking and the author has stated that they don't intend to. Wild doesn't do incremental linking yet, but that is the end-goal. By writing Wild in Rust, it's hoped that the complexity of incremental linking will be achievable.

Can someone explain what is so special about Rust for this?

replies(11): >>42814916 #>>42814925 #>>42814952 #>>42814958 #>>42814975 #>>42815031 #>>42815056 #>>42815091 #>>42815564 #>>42816061 #>>42816644 #
senkora ◴[24 Jan 25 16:51 UTC] No.42814952[source]▶
I assume that he is referring to "fearless concurrency", the idea that Rust makes it possible to write more complex concurrent programs than other languages because of the safety guarantees:

https://doc.rust-lang.org/book/ch16-00-concurrency.html

So the logic would go:

1. mold doesn't do incremental linking because it is too complex to do it while still being fast (concurrent).

2. Rust makes it possible to write very complex fast (concurrent) programs.

3. A new linker written in Rust can do incremental linking while still being fast (concurrent).

EDIT: I meant this originally, but comments were posted before I added it so I want to be clear that this part is new: (Any of those three could be false; I take no strong position on that. But I believe that this is the motivating logic.)

replies(2): >>42814984 #>>42814991 #
ComputerGuru ◴[24 Jan 25 16:54 UTC] No.42814991[source]▶
Actually a lot of the hacks that mold uses to be the fastest linker would be, ironically, harder to reproduce with rust because they’re antithetical to its approach. Eg Mold intentionally eschews used resource collection to speed up execution (it’ll be cleaned up by the os when the process exits) while rust has a strong RAII approach here that would introduce slowdowns.
replies(4): >>42815034 #>>42815095 #>>42815472 #>>42815635 #
1. Philpax ◴[24 Jan 25 16:57 UTC] No.42815034{3}[source]▶
I mean, that's pretty easy to do in Rust: https://doc.rust-lang.org/std/mem/struct.ManuallyDrop.html

Also see various arena allocator crates, etc.

replies(1): >>42815101 #
2. ComputerGuru ◴[24 Jan 25 17:03 UTC] No.42815101[source]▶
Not really. You would have to either wrap any standard library types in newtypes with ManuallyDrop implemented or (for some) use a custom allocator. And if you want to free some things in one go but not others that gets much harder, especially when you look at how easy a language like zig makes it.

And if you intentionally leak everything it is onerous to get the borrow checker to realize that unless you use a leaked box for all declaration/allocations, which introduces both friction and performance regressions (due to memory access patterns) because the use of custom allocators doesn’t factor into lifetime analysis.

(Spoken as a die-hard rust dev that still thinks it’s the better language than zig for most everything.)

replies(1): >>42815448 #
3. Aurornis ◴[24 Jan 25 17:37 UTC] No.42815448[source]▶
> You would have to either wrap any standard library types in newtypes with ManuallyDrop implemented

ManuallyDrop would presumably be implemented on large data structures where it matters, not on every single type involved in the program.