←back to thread

Wild – A fast linker for Linux

(github.com)
383 points hkalbasi | 4 comments | 24 Jan 25 16:25 UTC | HN request time: 0.906s | source
Show context
pzmarzly ◴[24 Jan 25 16:55 UTC] No.42815005[source]▶
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.
replies(5): >>42815102 #>>42815606 #>>42816517 #>>42819089 #>>42819826 #
secondcoming ◴[24 Jan 25 17:03 UTC] No.42815102[source]▶
Maybe I'm holding it wrong, but mold isn't faster at all if you're using LTO, which you probably should be.
replies(6): >>42815189 #>>42815221 #>>42815904 #>>42816102 #>>42816403 #>>42840365 #
Arelius ◴[24 Jan 25 19:09 UTC] No.42816102[source]▶
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.

replies(4): >>42816339 #>>42816648 #>>42823665 #>>42824951 #
1. jcalvinowens ◴[24 Jan 25 20:32 UTC] No.42816648[source]▶
If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...
replies(1): >>42817282 #
2. paulddraper ◴[24 Jan 25 21:53 UTC] No.42817282[source]▶
Sure, for that 1% of the time.
replies(1): >>42817685 #
3. thesz ◴[24 Jan 25 22:49 UTC] No.42817685[source]▶
...which takes these remaining 99% of a development time...
replies(1): >>42819472 #
4. saagarjha ◴[25 Jan 25 04:22 UTC] No.42819472{3}[source]▶
Surely your LTO bugs are not so easy to fix that they take less time to resolve than linking itself does.