Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wild – A fast linker for Linux

github.com

Post reply on HN
Print view View original

181–190 of 222 posts

Re: Wild – A fast linker for Linux

#181

Post by ajb »

kibwen wrote: post #177
einpoklum wrote: post #158

Earlier quoted context omitted.

Can you name a few of these features, for those of us who don't know much about linking beyond the fact that it takes compiled object files and makes an executable (and maybe does LTO)?

Presumably they're talking about linker scripts, and IMO if you're one of the vanishingly rare people who absolutely needs a linker script for some reason, then, firstly, my condolences, and secondly, given that 99.999% percent of users never need linker scripts, and given how much complexity and fragility their support adds to linker codebases, I'm perfectly happy to say that the rest of us can happily use fast and…

Anyone wondering why you'd need a linker script: They are essential on bare metal, as you have to tell the linker where the hardware requires you to put stuff. There are lots in the linux kernel repo, u-boot, probably Arduino, etc.

Re: Wild – A fast linker for Linux

#182

Post by p_ing »

cyco130 wrote: post #130
jcelerier wrote: post #128

Earlier quoted context omitted.

OTOH even lld, fast but fairly slower than mold, is already incredibly faster than MS's linker even without the incrmeentality. Like, I'm routinely linking hundreds of megabytes in less than a second anyways, not sure incrementality is that much worth it

Not a rhetorical question: Could it be that part of the speed difference is due to the file system speed? I was shocked when I saw how much modern(ish) Windows file systems were slower than modern(ish) Linux ones.

NTFS and ReFS are high performance file systems. But yes, it is due to file system filters, which OOTB means Windows Defender, though that can be extended by 3rd parties, including Sysinternals utils such as procmon.

Microsoft built a very extensible I/O stack and prior to Defender/prior to SSDs it really wasn't very noticable... back when it was originally designed well through the 90s and early 00s.

Unfortunately it is now noticable despite being an otherwise smart design. Which means Windows and/or NTFS are blamed as being slow, neither of which has any basis in fact when we look at the overall design of Windows' subsystems/VMM in comparison to macOS/Linux.

It sucks. You've got great plumbing in Windows with a shit shell on top.

Re: Wild – A fast linker for Linux

#183

Post by pjmlp »

yosefk wrote: post #178
pjmlp wrote: post #91

Earlier quoted context omitted.

C++ can be rather faster to compile than Rust, because some compilers do have incremental compilation, and incremental linking. Additionally, the acceptance of binary libraries across the C and C++ ecosystem, means that more often than not, you only need to care about compiling you own application, and not the world, every time you clone a repo, or switch development branch.

compiling crates in parallel is fast on a good machine. OTOH managing C++ dependencies without a standard build & packaging system is a nightmare

Imagine if Linus needed a gaming rig to develop Linux...

And he also did not had cargo at his disposal.

No need to point out it is C instead, as they share common roots, including place of birth.

Or how we used to compile C++ between 1986 and 2000's, mostly in single core machines, developing games, GUIs and distributed computing applications in CORBA and DCOM.

Re: Wild – A fast linker for Linux

#184

Post by mshockwave »

kibwen wrote: post #177
einpoklum wrote: post #158

Earlier quoted context omitted.

Can you name a few of these features, for those of us who don't know much about linking beyond the fact that it takes compiled object files and makes an executable (and maybe does LTO)?

Presumably they're talking about linker scripts, and IMO if you're one of the vanishingly rare people who absolutely needs a linker script for some reason, then, firstly, my condolences, and secondly, given that 99.999% percent of users never need linker scripts, and given how much complexity and fragility their support adds to linker codebases, I'm perfectly happy to say that the rest of us can happily use fast and…

It’s pretty common to roll your own linker script in embedded software development

Re: Wild – A fast linker for Linux

#186

Post by Defletter »

mistercheph wrote: post #167
Defletter wrote: post #159

Earlier quoted context omitted.

Is it? Because open source tools re-licensing themselves to be more permissive would seem to indicate whose loss it really is.

Embrace, extend, extinguish. it could take about a century, but every software company (hardware maybe next century) is in the process of being swallowed by free software. Thats not to say people can’t carve out a niche and have balling corporate retreats for a while.. until the sleeping giant wakes up and rolls over you.

You've just made a pretty outrageous claim without evidence that would require a lot of effort on my part to refute, so I'll just go with: if you say so.

Re: Wild – A fast linker for Linux

#187

Post by iknowstuff »

bjourne wrote: post #179
davidlattimore wrote: post #94

Earlier quoted context omitted.

It sounds like you're building from scratch. In that case, the majority of the time will be spent compiling code, not linking. The case for fast linkers is strongest when doing iterative development. i.e. when making small changes to your code then rebuilding and running the result. With a small change, there's generally very little work for the compiler to do, but linking is still done from scratch, so tends to domi…

True, I didn't think of that. However, the root cause here perhaps is fat binaries? My preferred development flow consists of many small self-contained dynamically linked libraries that executables link to. Then you only have to relink changed libraries and not executables that depend on them.

So is this your preferred flow because of slow linkers?

Re: Wild – A fast linker for Linux

#188

Post by dspearson »

cies wrote: post #175
panzi wrote: post #133

Earlier quoted context omitted.

Why does AGPL Vs MIT matter for a linker?

iirc the mold author wanted to make money off of it (and I dont blame him). AGPL is avoided like the plague by big corps: same big corps are known for having money to pay for licenses and sometimes (yes, I look at you Amazon) being good at deriving value from FLOSS without giving back. iirc AGPL was used so everyone can just use it, big biz is still compelled to buy a license. this has been done before and can be see…

Under what circumstances would commercial companies be required to buy a license?! If they provide Linking as a Service?

Re: Wild – A fast linker for Linux

#189

Post by IshKebab »

Arelius wrote: post #60
secondcoming wrote: post #27

Earlier quoted context omitted.

Maybe I'm holding it wrong, but mold isn't faster at all if you're using LTO, which you probably should be.

Yeah, if you're development process requires LTO you may be holding it wrong.... Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.

> you're development process requires LTO you may be holding it wrong....

Not necessarily. LTO does a very good job of dead code elimination which is sometimes necessary to fit code in microcontroller memory.

Re: Wild – A fast linker for Linux

#190

Post by cies »

dspearson wrote: post #188
cies wrote: post #175

Earlier quoted context omitted.

iirc the mold author wanted to make money off of it (and I dont blame him). AGPL is avoided like the plague by big corps: same big corps are known for having money to pay for licenses and sometimes (yes, I look at you Amazon) being good at deriving value from FLOSS without giving back. iirc AGPL was used so everyone can just use it, big biz is still compelled to buy a license. this has been done before and can be see…

Under what circumstances would commercial companies be required to buy a license?! If they provide Linking as a Service?

They probably wont NEED a license, but --as said-- big corps dont touch AGPL with a ten foot pole because legal. So it's just to shut up legal, most likely.
Post reply on HN