Wild – A fast linker for Linux
github.com
Wild – A fast linker for Linux
1–10 of 222 posts
Re: Wild – A fast linker for Linux
#2[deleted]
Re: Wild – A fast linker for Linux
#3[deleted]
[deleted]
Re: Wild – A fast linker for Linux
#4> 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?
Re: Wild – A fast linker for Linux
#5> 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?
[flagged]
Re: Wild – A fast linker for Linux
#6> 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?
I assume they're referring to thread-safety and the ability to more aggressively parallelize.
Re: Wild – A fast linker for Linux
#7I think the optimal approach for development would be to not produce a traditional linked executable at all, but instead just place the object files in memory, and then produce a loader executable that hooks page faults in those memory areas and on-demand mmaps the relevant object elsewhere, applies relocations to it, and then moves it in place with mremap.
Symbols would be resolved based on an index where only updated object files are reindexed. It could also eagerly relocate in the background, in order depending on previous usage data.
This would basically make a copyless lazy incremental linker.
Re: Wild – A fast linker for Linux
#8> 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?
[flagged]
I guess they meant that why write in Rust.
Re: Wild – A fast linker for Linux
#9> 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?
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.)