The Speed Of LLVM's LLD Linker Continues Looking Good

[lowflyer]

My original argument is completely lost at this point: code quality matters more than compile/link time.

Let me address the other points:

Several teams of engineers have invest man-years of labor working to make faster linkers. I think they deserve a metric ton of hero cookies.

Well, ... yes. Credit where credit's due. I don't intend to demean any of the work done on the linkers. But 10 Kg of cookies are enough. I'd rather like to see better code.

Please, take the time to answer my questions re: where you feel that time is squandered in the edit-compile-test cycle, and please give some consideration to my assertion that programmers have zero control over how long the final link takes, vs startup time - which you assert takes so much longer that link time is irrelevant.

The expression "edit-compile-test" cycle tells already that there are three phases, all of which take their time.

• The edit phase is the one that should take the most time. There are cases where you just fix "mishaps" or typos that only take seconds to correct. But constantly jumping from small-fix to the next small-fix is wasting time. And yes, you are wasting linker time. But the fix for this is not a faster linker - it is: better thought-through edits. Time spent in carefully crafting the next edit is what *really* reduces development time.
• Developers *do* have some control over the link time by carefully combining static and dynamic linking. Move link-expensive parts to a dynamic libraries which will link faster because of fewer symbol entries.
• It is not always possible to keep testing in the millisecond range. Bare program startup times may already be significant. State-machines which need to be put into a specific state before, network code that depends on external servers, user interfaces that depend on user input, test-cases that depend on gigabytes of loaded data. In nearly every project you have one of these cases.

Considering that developers have some control over both, the linking time and the testing time, I think that there are only very rare cases where the linker time is really a significant contributor to the overall development time.

In my own experience I am able to code a few jumps which to take me near-instantly to my test case and startup time is in the low milliseconds, but I've never been able to achieve such a time savings with a linker, so for me the linker is always the one thing I am waiting on.

I think this is "normal coding practice". We're using it where appropriate.

I've also asked you to try actually timing your final link and considering whether you feel waiting for that 100x a day is a good use of your developer man hours.

Here is where we disconnect. You seem to concentrate on speeding up the edit-compile-test cycle. This is not wrong per-se. A "fluid" edit-compile-test cycle is the basis of every good development process. But if it is the only thing you're concentrating on, you'll miss the boat. There is an simultaneous/alternate truth here: If you are able to reduce the number of cycles you'll save developer man hours. You can also look at it from the other side: the limiting factor is the "cycles" itself.
Think about the guy spoon-editing one line at a time and then "having to wait for the linker". That's your scenario. If you give that guy a faster linker he will be faster at wasting time in the linker...
As you see from my first comment-line, I put a high value to code quality. If you see one of your guys revolving in a 5-second-edit loop, think about the effort it requires to carefully craft a good quality edit. 5-second-edits will not produce quality - it may be an indication of bad code. Hit the brakes before that guy burns out!.

LDD might save you some labour $$$ and/or help get your product to market sooner. Maybe your developers will think you're a superhero when you bring them LDD. Maybe they'll think you're a slave driver, if they enjoyed the little breaks, lol...

Without having introduced LDD, my colleagues already call me a superhero. There's need for a better title ... ;-)

But seriously, as much as I'd like to introduce LDD (and Clang) we currently have not the option to move to LDD because of third party libraries.

[ldo17]

... and possibly you can bring them LDD and they will love you for it.

You mean you don’t use it already?

[linuxgeex]

My original argument is completely lost at this point: code quality matters more than compile/link time.

I never said I disagreed with that assertion. I only mentioned that a faster linker can lead to better code quality.

Here is where we disconnect. You seem to concentrate on speeding up the edit-compile-test cycle. This is not wrong per-se. A "fluid" edit-compile-test cycle is the basis of every good development process. But if it is the only thing you're concentrating on, you'll miss the boat. There is an simultaneous/alternate truth here: If you are able to reduce the number of cycles you'll save developer man hours. You can also look at it from the other side: the limiting factor is the "cycles" itself.
Think about the guy spoon-editing one line at a time and then "having to wait for the linker". That's your scenario. If you give that guy a faster linker he will be faster at wasting time in the linker...
As you see from my first comment-line, I put a high value to code quality. If you see one of your guys revolving in a 5-second-edit loop, think about the effort it requires to carefully craft a good quality edit. 5-second-edits will not produce quality - it may be an indication of bad code. Hit the brakes before that guy burns out!.

I'm sorry, I know I shouldn't sink to your level of ridiculousness, but you just make it so tempting lol... so here we go:

If lengthy link times are really as great as you think they are, perhaps you could improve the efficiency of your developer teams by slowing down their existing linker, lol. Heck, let's bring it to a complete stop! Imagine the quality of code that was never linked at all! They'd have to get it perfect!!!

[lowflyer]

For a minute, I was under the impression you were able for a nice discussion...

I never said I disagreed with that assertion. I only mentioned that a faster linker can lead to better code quality.

No, you quite disagreed with my initial post. You even mentioned:

Actually, the speed of a linker is paramount to code quality.

Which I obviously oppose: The "quality" of the guy using a linker is paramount to final code quality. If the linker time gets in the way of development, then do something about it. There are many things *any* developer can do - I've mentioned a few. But I battle to understand how linker time improvement from 60 seconds to 45 seconds shall be a game changer.

The real skill of a software developer is to know how to make use of the tools he has. This is a very general truth. It's not even limited to software development: A house cleaner that knows how to use a dirty old rug is able to clean your house a lot better than you are with all swiffers, sniffers and fluffers money can buy.

-> It's not the Tools that make the difference, its the Skillz of the guy using it!

I'm sorry, I know I shouldn't sink to your level of ridiculousness,

Well, then don't. - But against better knowledge you contiue:

but you just make it so tempting lol... so here we go:

If lengthy link times are really as great as you think they are, perhaps you could improve the efficiency of your developer teams by slowing down their existing linker, lol. Heck, let's bring it to a complete stop! Imagine the quality of code that was never linked at all! They'd have to get it perfect!!!

Look, I've never ever mentioned that lengthy link times are great. I also commended the efforts to improve the linkers.

You still seem to be stuck in the old C-compiler wars back in the 80's of last millennium, where Aztec and Lattice were fighting to be the "fastest compiler". As a reminder: both of them have lost that war, both are out of business, both have been replaced by better alternatives.

It is my guess that you need to evolve too.

[linuxgeex]

For a minute, I was under the impression you were able for a nice discussion...



No, you quite disagreed with my initial post. You even mentioned:


Which I obviously oppose: The "quality" of the guy using a linker is paramount to final code quality. If the linker time gets in the way of development, then do something about it. There are many things *any* developer can do - I've mentioned a few. But I battle to understand how linker time improvement from 60 seconds to 45 seconds shall be a game changer.

The real skill of a software developer is to know how to make use of the tools he has. This is a very general truth. It's not even limited to software development: A house cleaner that knows how to use a dirty old rug is able to clean your house a lot better than you are with all swiffers, sniffers and fluffers money can buy.

-> It's not the Tools that make the difference, its the Skillz of the guy using it!




Well, then don't. - But against better knowledge you contiue:



Look, I've never ever mentioned that lengthy link times are great. I also commended the efforts to improve the linkers.

You still seem to be stuck in the old C-compiler wars back in the 80's of last millennium, where Aztec and Lattice were fighting to be the "fastest compiler". As a reminder: both of them have lost that war, both are out of business, both have been replaced by better alternatives.

It is my guess that you need to evolve too.

Wow, how you turn my commendation for saving developer frustration in order to improve code quality, and recommending that you try actually testing it, and recommending that you adopt the new technology - into you turning around and making an ad-hominem attack that I "need to evolve" - pot kettle black much dude. I hope you're proud of yourself.

[lowflyer]

Wow, how you turn my commendation for saving developer frustration in order to improve code quality, and recommending that you try actually testing it, and recommending that you adopt the new technology - into you turning around and making an ad-hominem attack that I "need to evolve" - pot kettle black much dude. I hope you're proud of yourself.

Well, it was actually you that started it:

I'm sorry, I know I shouldn't sink to your level of ridiculousness, <snip/>

"wie man in den Wald ruft ..."


Are you able to at least admit that the skill set of a software developer matters?

Did I hit with mentioning Aztec and Lattice?