2026-08-25
Every time you compile a large C++ program, there's a step at the very end called linking. Think of it like this: the compiler translates each source file into a bag of puzzle pieces (object files), and the linker snaps them all together into one finished executable. It resolves the "hey, this function lives over there" references between files, lays out the final binary in memory, and produces the program you actually run.
The problem: linking has been painfully slow for decades. If you're a developer working on a huge codebase like Chromium or LLVM, you might change one line of code, hit compile, and then wait 30+ seconds while the linker chugs along using essentially one CPU core, while your other 15 cores sit idle. That wait is death for productivity — it breaks the tight "edit, compile, test" feedback loop that makes programming pleasant.
Enter mold, a new open-source linker by Rui Ueyama (who also wrote lld, the LLVM linker). The core insight is almost embarrassingly simple: link in parallel, everywhere possible. Existing linkers were built in an era when parallelism was an afterthought, so they use a serial pipeline with maybe one or two parallelized passes bolted on. Mold rethinks the whole pipeline with data parallelism as the first-class design principle.
What does that mean concretely?
The result: mold links large binaries several times faster than the previous state of the art (GNU gold and LLVM lld), often finishing in seconds what used to take half a minute. For a giant target like Chrome, that shaves real wall-clock time off every single developer iteration.
What makes this paper worth reading isn't a fancy algorithm — it's a case study in what happens when someone takes a piece of decades-old infrastructure and asks, "what would this look like if we designed it today?" Linking was widely assumed to be inherently serial in parts. Mold shows that assumption was mostly just inertia.