8 ms·
Mold 1.0: the first stable and production-ready release of the high-speed linker
- jsnell 5y agoPre-1.0 discussion: https://news.ycombinator.com/item?id=26233244 https://news.ycombinator.com/item?id=26233244 (122 comments)
- orra 5y agoIn the previous discussion we discussed how fast mold is at linking ELF files. I was also wondering (unvoiced) if it would also be possible to make a ridiculously fast linker for PE/COFF (Windows). Somebody else asked the same question in an issue and the answer is yes, in principle, but it'll take a lot of work. That's not unlike how solid ELF support took a lot of work. I see in the v1.0 release notes, Windows support is nominally planned for v3.0.
- nitsky 5y agoI have been using mold every day for almost a year, and it has dramatically improved my quality of life by decreasing link times on the Rust project I work on from approximately 10 seconds to less than one second. This makes a big difference in keeping focus during the edit-compile-run loop. Thank you!
- c0balt 5y agoMaybe a dumb question but how would I go about using it with rust(c) and cargo? Would love to try it out, if it decreases total compile times.
- the_duke 5y agoRUSTFLAGS="-C linker=clang -C link-arg=-fuse-ld=/path/to/mold" cargo build or persitant in your project: .cargo/config.toml [target.x86_64-unknown-linux-gnu] linker = "clang" rustflags = ["-C", "link-arg=-fuse-ld=/PATH/TO/mold"]
- c0balt 5y agoThank you. Will try it later
- fbernier 5y ago-fuse-ld has been replaced by --ld-path in clang 12+
- the_duke 5y agoGood to know, thanks. fuse-ld still works though.
- wyldfire 5y agoI wonder -- "-fuse-ld" has some somewhat surprising behavior in how clang ends up discovering the linker. I think that even if clang has a sibling `lld` in the same distribution, "-fuse-ld=lld" will pick "ld.lld" from the $PATH if it's present in there before the directory where clang and lld are installed. So maybe that "--ld-path" option helps resolve ambiguity by expecting an explicit path instead of a linker name.
- 4khilles 5y ago"mold -run cargo build" would also work.
- the_duke 5y agoWarning: don't do this if you use rust-analyzer or any other IDE that uses cargo check. The flags are part of the cache hash, so your IDE and cli constantly invalidate the cache and compile from scratch.
- tomcam 5y ago> decreasing link times on the Rust project I work on from approximately 10 seconds to less than one second. But enough about writing “hello, world“ programs in Rust. I kid.
- igorkraw 5y agoAnyone know the state of link time optimisation on this? Last time I checked it was advised to use this for dev builds only
- tux3 5y agoLTO is planned, but not a priority. I think the author will work on macOS support next, before anything else.
- CyberRabbi 5y agoI initially had the same question but seeing the author’s comments on this feature (which are generally positive) I personally have come to the conclusion that it is a misfeature. LTO is not necessary for development builds, or builds where the speed of the write-compile-test loop matter. This is exactly the use case that mold was designed for and it is designed well. Adding LTO support would only add bloat to the code especially since mold’s techniques to improve the efficiency of linking don’t really apply to LTO (where link time is dominated by whole program analysis). I have no issue using the compiler’s native linker when doing production LTO builds and conceptually that makes more sense to me anyway. I would prefer it if the author avoided features when doing so benefits innovating on the core use case.
- gavinray 5y agoFWIW, the author is also the original author of LLVM's "lld" linker, and has written multiple C compilers. That makes them the author of both of the two fastest linkers in existence, AFAIK. This person has a very impressive resume. https://github.com/rui314/mold/blob/main/docs/design.md https://github.com/rui314/mold/blob/main/docs/design.md > "Concretely speaking, I want to use the linker to link a Chromium executable (~1.8 GiB in size) just in 1 second. LLVM's lld, the fastest open-source linker which I originally created a few years ago, takes about 12 seconds to link Chromium on my machine. So the goal is 12x performance bump over lld. Compared to GNU gold, it's more than 50x." There is good discussion as well in this prior post, and Reddit thread with the author in it a while back: https://news.ycombinator.com/item?id=26233244 https://news.ycombinator.com/item?id=26233244 https://www.reddit.com/r/cpp/comments/kxvw5c/mold_a_modern_linker/ https://www.reddit.com/r/cpp/comments/kxvw5c/mold_a_modern_l...
- wyager 5y agoWhy is Chromium so huge?
- tomcam 5y agoWhat would you do to shrink it?
- wyager 5y agoThat would require me knowing the answer to the question I asked.
- rackjack 5y agoThis might be a nerd-sniping question because there are lots of reasons and people will fight over which ones are most relevant. e.g. V8, rendering, myriad web protocols, security measures, etc. From my understanding at least.
- glandium 5y agoDebug info is huge.
- citrin_ru 5y ago> As soon as the second process writes a result file to a filesystem, it notifies the first process, and the first process exits. The second process can take time to exit, because it is not an interactive process. Looks like a trade-off which may favor speed over reliability. If a syscall (like msync) in 2nd process will return an error there will no way to abort a build if 1st (main) process already has finished.
- PudgePacket 5y agohttps://abramov.io/rust-dropping-things-in-another-thread https://abramov.io/rust-dropping-things-in-another-thread
- CJefferson 5y agoThe second process doesn't technically report until it has closed references to the binary it is writing (last time I checked). If anything errors after that, it doesn't effect your created executable in any way.
- spekcular 5y agoDumb question: Why is this a separate project, instead of being an improvement to the LLVM linker (given they have the same author)? Does this have any chance of being adopted by LLVM?
- nmstoker 5y agoPerhaps because it's not just for LLVM? Given the comments in the repo README about it being a drop in replacement for the GNU linker, it looks like could be useful for several other scenarios too (but I defer to those who can explain this more clearly/correctly than I!)
- touisteur 5y agoIt can in fact link gcc-ada specific things and others.
- VWWHFSfQ 5y agoAccording to the rejected patch to GCC to support arbitrary linkers [0], mold or any other linker is probably not working very well with GCC. So unless they're wrong, this doesn't really seem like a generic drop-in solution anyway, despite trying to be one. [0] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573833.html https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573833.h...
- spekcular 5y agoThe key part: "Note, all these extra linkers (lld, mold) will not really work properly, gcc during configuration detects various assembler and linker properties on which it then relies on and I'm sure neither lld nor mold supports those features."
- wyldfire 5y agoAt the very least, lld is pretty much drop-in. Aside from some subtle differences about resolution order (IIRC lld implicitly has "--start-group"/"--end-group"), everything just works with lld in place of ld.bfd. My recollection was that I had just about the same experience w/gold -- it was just a drop-in replacement. All of my experience was with using clang as the driver, so I can't speak to why gcc has trouble making a similar feature work like expected.
- Mizza 5y agoI think this is an interesting model: https://github.com/rui314/mold/blob/main/LICENSE https://github.com/rui314/mold/blob/main/LICENSE I'm glad he's doing this as (A)GPL. It's great work and it's Free for the people. If you want the option for it to be private, feel free to step up and do the right thing.
- invokestatic 5y agoWhy Affero? Are there cloud linker tools? Or simply because it is one of the most restrictive open source licenses?
- wmf 5y agoI wonder about AGPL "infecting" proprietary CI pipelines.
- singron 5y agoPlease read the AGPL very carefully before saying things like this. There is no reasonable interpretation where some cli program in part of a CI pipeline would infect the result of the pipeline (i.e. build artifacts) unless it actually put itself into the result. (E.g. gcc puts a small amount of code from libgcc into the executable, but that explicitly has a different license). The "A" of the AGPL expands the distribution rules of the GPL to include network access but doesn't really expand the virality or combined-works parts. It "infects" your program just as much as any GPL program would.
- pantalaimon 5y agoDoes this also work for embedded targets?
- Ecco 5y agoIt does not intend to support linker scripts, which would be a problem for embedded. It also does not support LTO, and I dont think that a non-LTO link of an embedded executable can take any noticeable amount of time with any linker.
- U1F984 5y agoLots of interesting things in the design document: https://github.com/rui314/mold/blob/main/docs/design.md https://github.com/rui314/mold/blob/main/docs/design.md