[HN Gopher] Mold 1.0: the first stable and production-ready rele...
___________________________________________________________________
Mold 1.0: the first stable and production-ready release of the
high-speed linker
Author : matt_d
Score : 167 points
Date : 2021-12-15 16:52 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Mizza wrote:
| I think this is an interesting model:
| 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 wrote:
| Why Affero? Are there cloud linker tools? Or simply because it
| is one of the most restrictive open source licenses?
| kzrdude wrote:
| It's pretty clear we need AGPL when anything can be compiled
| to wasm soon.
| jcelerier wrote:
| Since WASM blobs would run in the end-user's browser, GPL
| is sufficient to allow the user to request source. AGPL is
| more useful for preventing e.g. cloud build services.
| Starlevel001 wrote:
| > most restrictive
|
| It's the least restrictive for user freedom.
| wmf wrote:
| I wonder about AGPL "infecting" proprietary CI pipelines.
| singron wrote:
| Please 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.
| wmf wrote:
| I don't mean the build artifacts; I mean the CI build
| scripts and such.
| infogulch wrote:
| Is that CI provided as a propietary service? If it
| applied, it would only apply to users of the CI service.
| So, publish your custom internal CI code to your own
| developers.
| orra wrote:
| There's certainly cloud IDEs.
| eitland wrote:
| Given the goals stated I think it is because it is the most
| restrictive license.
|
| In fact for many years this was the only value I saw in AGPL:
| to provide a best possible starting point for an upsell while
| claiming it was all about Free Software.
| spekcular wrote:
| Dumb 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 wrote:
| Perhaps 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 wrote:
| It can in fact link gcc-ada specific things and others.
| VWWHFSfQ wrote:
| According 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.h...
| spekcular wrote:
| The 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."
| citrin_ru wrote:
| > 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 wrote:
| https://abramov.io/rust-dropping-things-in-another-thread
| CJefferson wrote:
| The 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.
| igorkraw wrote:
| Anyone know the state of link time optimisation on this? Last
| time I checked it was advised to use this for dev builds only
| tux3 wrote:
| LTO is planned, but not a priority. I think the author will
| work on macOS support next, before anything else.
| CyberRabbi wrote:
| I 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 wrote:
| FWIW, 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
| > "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://www.reddit.com/r/cpp/comments/kxvw5c/mold_a_modern_l...
| wyager wrote:
| Why is Chromium so huge?
| simlevesque wrote:
| Back when I was using Gentoo, Chromium was the biggest
| dependency on my machine, by far. When there was an update I
| couldn't use my machine for like 30 minutes.
| rackjack wrote:
| This 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 wrote:
| Debug info is huge.
| jsnell wrote:
| Pre-1.0 discussion: https://news.ycombinator.com/item?id=26233244
| (122 comments)
| orra wrote:
| In 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 wrote:
| I 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 wrote:
| Maybe 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.
| 4khilles wrote:
| "mold -run cargo build" would also work.
| the_duke wrote:
| Warning: 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.
| the_duke wrote:
| RUSTFLAGS="-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"]
___________________________________________________________________
(page generated 2021-12-15 23:01 UTC)