Mold – A really fast linker • Hacker News Board

Re: Mold – A really fast linker

#31

Post by olig15 » Sat, Jan 14, 2023, 11:03 PM UTC

yazaddaruvala wrote: post #25

It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?

We make use of lots of distributed compiles at work which .o(bj) files are useful for, but to compile something locally it might be useful to keep things in memory - if all of the objects fit. The code base’s objects I work on won’t fit in ram, so will get paged to disk at some point during linking anyway

Re: Mold – A really fast linker

#32

Post by [deleted] » Sat, Jan 14, 2023, 11:06 PM UTC

yazaddaruvala wrote: post #25

It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?

[deleted]

Re: Mold – A really fast linker

#33

Post by [deleted] » Sat, Jan 14, 2023, 11:15 PM UTC

yazaddaruvala wrote: post #25

It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?

[deleted]

Re: Mold – A really fast linker

#34

Post by benreesman » Sat, Jan 14, 2023, 11:27 PM UTC

I always wanted to use mold in the build system I did last year: the metrics are fucking impressive.

There were subtle differences to gold and ldd that I didn’t have time to chase down, but it seems like the future.

Re: Mold – A really fast linker

#35

Post by rcme » Sat, Jan 14, 2023, 11:29 PM UTC

yazaddaruvala wrote: post #25

It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?

Seems like it’d be useful to have .o files on disk for incremental compilation.

Re: Mold – A really fast linker

#36

Post by mgaunard » Sat, Jan 14, 2023, 11:30 PM UTC

benreesman wrote: post #34

I always wanted to use mold in the build system I did last year: the metrics are fucking impressive. There were subtle differences to gold and ldd that I didn’t have time to chase down, but it seems like the future.

I can't say I've noticed much of a difference myself, maybe 20% faster at best.

Re: Mold – A really fast linker

#37

Post by guenthert » Sat, Jan 14, 2023, 11:37 PM UTC

yazaddaruvala wrote: post #25

It seems odd to me that we still require .o files at all. Given the final program needs to be storable in RAM + Virtual Memory it surprises me that we still need the intermediate step of pushing to the file system only to then immediately reopen and merge those files. Does someone have more info on this? Or is the reason just legacy? Or is the reason just some ideological “single responsibility” thing?

Well, you might know that all those source files belong to exactly one executable (or library), but how would the compiler know?

Re: Mold – A really fast linker

#38

Post by guenthert » Sat, Jan 14, 2023, 11:40 PM UTC

Y_Y wrote: post #19

satvikpendem wrote: post #2

Note that there have been some license controversies with mold before, namely that they wanted to make all outputs AGPL, not simply mold itself [0], seems like they walked this policy back however [1]. > Open-source license: mold stays in AGPL, but _we claim AGPL propagates to the linker's output_. That is, we claim that the output from the linker is a derivative work of the linker. That's a bold claim but not entire…

So just use mold during development and another linker for release.

Which do you use for testing?

Re: Mold – A really fast linker

#39

Post by benreesman » Sat, Jan 14, 2023, 11:45 PM UTC

mgaunard wrote: post #36

benreesman wrote: post #34

I always wanted to use mold in the build system I did last year: the metrics are fucking impressive. There were subtle differences to gold and ldd that I didn’t have time to chase down, but it seems like the future.

I can't say I've noticed much of a difference myself, maybe 20% faster at best.