Mold 1.1 High Performance Linker Brings Native LTO, RISC-V Support

[Raka555]

0. Deferring performance related work to an unspecified point in the future is a good way to make sure performance never comes. An entire project might remain a suboptimal piece of crap until it is rewritten from scratch if it follows that approach.
1. Of course something incorrect is useless, no matter how fast it runs. However you need benchmarks from the very beginning (even if initially the performance is poor) to show the progress you make over time. I believe benchmarks just like correctness test should be run from the beginning of the development.
2. Those guys were posting benchmarks (and I agree with their decision) before their linker was even close to correct (it didn't even support LTO at that time). Weren't they focusing on correctness then?



I do not expect any difference in the produced binary, but you never know. That's why I think having it benchmark is useful (expecting similar scores).
I also do not expect the same % speed-up for LTO as for non-LTO, for the reason you said (most time taken is constant independent of the linker). I would expect similar benefits in absolute time (in seconds) though.

I usually commit the time the test suite took to run, as part of the commit message.
It is easy to spot then if you made changes that causes a regression in speed.

One don't have to premature optimize, but you have make sure you don't premature regress as well...

[marios]

Not implementing an optional feature is very different from claiming to implement it but producing buggy code when you actually use it.

LTO is only optional if you don't care about performance. With the same reasoning, eating is optional if you don't care about life...
I get the difference, but still in either case LTO is basic functionality that should work for any linker version 1.0 (implying that it is ready for wide use).

[eva2000]

Performance of produced executables will be the same across linkers. With LTO (just like non-LTO) compiler is doing all the work of (compiling and) optimizing. Linker does not significantly affect performance of produced executables.

Build times will also be about the same with different linkers. Linking is only small part of overall build time.

Yeah, that's what I'm finding too with Nginx and FFMPEG binary compilation compared to ld.gold and ld.bfd - difference isn't that much.

[smitty3268]

LTO is only optional if you don't care about performance. With the same reasoning, eating is optional if you don't care about life...
I get the difference, but still in either case LTO is basic functionality that should work for any linker version 1.0 (implying that it is ready for wide use).

99.9% of compiles don't use LTO.

99% don't even enable optimizations.

Your personal use case doesn't have to be what they target. It's far better for them to state that up front, rather than claiming otherwise and causing you to investigate the project just to get pissed off when you realize it's broken.

[marios]

99.9% of compiles don't use LTO.

99% don't even enable optimizations.

Your personal use case doesn't have to be what they target. It's far better for them to state that up front, rather than claiming otherwise and causing you to investigate the project just to get pissed off when you realize it's broken.

I agree that is far better to say "my linker does not work" if your linker doesn't work. Where I disagree is claiming that LTO is an optional feature.
Considering the percentages that you posted I can only say this: It is known...

PS: Fortunately this discussion has only philosophical value, since there is mold 1.1 that has this (optional by your standards, mandatory by my standards) feature.

[Raka555]

99% don't even enable optimizations.

Well, they should:

https://medium.com/swlh/a-performance-comparison-between-c-java-and-python-df3890545f6d

[smitty3268]

Well, they should:

https://medium.com/swlh/a-performanc...n-df3890545f6d

I think you're missing my point.

Most compiles don't enable optimization because they are done by developers who are debugging their code.

The speed of the final binary is mostly meaningless in that scenario. The primary limiting factor to how productive you are is based on how fast you can test changes you are making in the codebase, which means fast compile times are paramount. Optimizations are slow, and LTO in particular is even slower.

Obviously that isn't always true, there can be exceptions to everything. Sometimes runtime performance is important, I'm just pointing out that the people who enjoy running Gentoo and tweaking their optimizations to the max are not the typical use case for a compiler. The vast majority of end users are just going to use precompiled packages from their distro which clearly aren't going to be moving to a brand new linker anytime soon either.