The Mold Linker Is Great & Set To Become Even Better

[plonoma]

Candida would be free

LOL no, having (the) MUMPS (programming language) in hospitals is more than enough!

[discordian]

The developers should really rename their project.

Candida would be free

[plonoma]

The developers should really rename their project.

[david-nk]

seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)

I would. Linking a debug build of a small to medium sized project takes 15 minutes on Windows, which basically makes debugging at work impossible, I have to do all debugging during home office. If I can pay for a linker that cuts these 15 minutes down to a few seconds, I'd buy it, unless it costs thousands of dollars for a license.

[bug77]

seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)

I know people and companies are as cheap as they get. Still, it's no reason for guys doing this kind of work to go unpaid... Remember heartbleed?

[intelfx]

LTO binaries are not really linked together. The compiler does the "linking" by doing the last compiling step. So in that case any linker speed improvements would be gone.

I don’t think that’s true. Even if LTO means that instead of linking many objects together you hand them back to the link-time frontend and all you get from the final stage of the backend (LTRANS, in GCC terminology) is a single object (which, btw, moght not be true anymore given that partitioned/parallel LTO exists) — it’s still an object which needs to be relocated, sections need to be laid out in memory (and possibly rearranged and GC’ed), the symbol tables need to be computed, in short, it needs to be linked.

[NobodyXu]

Thanks Azpegath , so it's now using linker plugin.

But my point remains - with LTO, it's essentially performing optimization at link-time using the compiler and then doing the codegen, I don't think it can speed it up a lot.

Linker plugin or jot, no one is going to reimplement all the code in LLVM/GCC for performing optimization, so it just can't help much with LTO.

If you want a faster LTO release build, then you would probably want to use ThinLTO from clang, it's multithreaded and should be faster than fat LTO which is single thread but optimizes stuff better.

[carewolf]

So I'm getting the impression that it does its own LTO, based on the IR output from the compiler that uses it?

Why would you get that impression? The link you quoted just said it used to just call the other linker (which would then call the compiler), now it can call the compiler directly itself instead. A linker is not a compiler, it can not handle LTO binaries.

[carewolf]

I don't understand the premise of the question.

LTO binaries are not really linked together. The compiler does the "linking" by doing the last compiling step. So in that case any linker speed improvements would be gone.

[rene]

Crap. When I read this article, I immediately thought "oh good, that guy found himself a revenue stream so he can keep soldiering on". I guess not, that's a shame

seriously just a linker is not really something anyone would spend money on. Even for a whole compiler suite the days have long sailed decades ago, ... You will be surprised how many users don't even want to pay for their Linux distribution ;-)