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

161–170 of 222 posts

Re: Wild – A fast linker for Linux

#161

Post by usr1106 »

panzi wrote: post #133
pzmarzly wrote: post #19

Ever since mold relicensed from AGPL to MIT (as part of mold 2.0 release), the worldwide need for making another fast linker has been greatly reduced, so I wasn't expecting a project like this to appear. And definitely wasn't expecting it to already be 2x faster than mold in some cases. Will keep an eye on this project to see how it evolves, best of luck to the author.

Why does AGPL Vs MIT matter for a linker?

Hmm, my naive summary of AGPL is "If you run AGPL code in your web backend you are obliged to offer the backend source to everyone using a web client". No wonder it's explicitly forbidden at Google.

What does that mean for a linker? If you ship a binary linked with an AGPL linker you need to offer the source of the linker? Or of the program being linked?

Re: Wild – A fast linker for Linux

#162

Post by nicoburns »

usr1106 wrote: post #161
panzi wrote: post #133

Earlier quoted context omitted.

Why does AGPL Vs MIT matter for a linker?

Hmm, my naive summary of AGPL is "If you run AGPL code in your web backend you are obliged to offer the backend source to everyone using a web client". No wonder it's explicitly forbidden at Google. What does that mean for a linker? If you ship a binary linked with an AGPL linker you need to offer the source of the linker? Or of the program being linked?

In practice I think it's pretty much equivalent to the GPL for a linker. But I can understand why people in commercial settings are wary of this license.

Re: Wild – A fast linker for Linux

#163

Post by sylware »

o11c wrote: post #150
sylware wrote: post #109

Earlier quoted context omitted.

ELF(COFF) should now be only an assembler output format on modern large hardware architecture. On modern large hardware architecture, for executable files/dynamic libraries, ELF(PE[+]) has overkill complexity. I am personnally using a executable file format of my own I do wrap into an "ELF capsule" on linux kernel. With position independent code, you kind of only need memory mapped segments (which dynamic libraries a…

You're giving up a lot if you stop using a format that supports multiple mapping, relro, dynamic relocations, ...

This is where the "scam" from those excessively complex formats is: I, pertinently, do not give up a lot since I get the job done... but on the other side, I gain the removal of tons and tons of complexity, and nullify significant developer/vendor lock-in at the same time.

A good analogy to "feel" that, it is a bit like "json vs xml" but for executable binary formats.

But, I keep in mind, those formats (excrutiatingly simple) can work only on modern hardware architectures.

Re: Wild – A fast linker for Linux

#164

Post by einpoklum »

davidlattimore wrote: post #124
KerrAvon wrote: post #103

I'm curious: what's the theory behind why this would be faster than mold in the non-incremental case? "Because Rust" is a fine explanation for a bunch of things, but doesn't explain expected performance benefits. "Because there's low hanging concurrent fruit that Rust can help us get?" would be interesting but that's not explicitly stated or even implied.

I'm not actually sure, mostly because I'm not really familiar with the Mold codebase. One clue is that I've heard that Mold gets about a 10% speedup by using a faster allocator (mimalloc). I've tried using mimalloc with Wild and didn't get any measurable speedup. This suggests to me that Mold is probably making heavier use of the allocator than Wild is. With Wild, I've certainly tried to optimise the number of heap a…

Rust is a perfectly fine language, and there's no reason you should not be able to implement fast incremental linking using Rust, so - I wish you success in doing that.

... however...

> code patterns that are fine in Rust due to the borrow checker, would be footguns in languages like C or C++,

That "dig" is probably not true. Or rather, your very conflation of C and C++ suggests that you are talking about the kind of code which would not be used in modern C++ of the past decade-or-more. While one _can_ write footguns in C++ easily, one can also very easily choose not to do so - especially when writing a new project.

Re: Wild – A fast linker for Linux

#165

Post by panstromek »

einpoklum wrote: post #164
davidlattimore wrote: post #124

Earlier quoted context omitted.

I'm not actually sure, mostly because I'm not really familiar with the Mold codebase. One clue is that I've heard that Mold gets about a 10% speedup by using a faster allocator (mimalloc). I've tried using mimalloc with Wild and didn't get any measurable speedup. This suggests to me that Mold is probably making heavier use of the allocator than Wild is. With Wild, I've certainly tried to optimise the number of heap a…

Rust is a perfectly fine language, and there's no reason you should not be able to implement fast incremental linking using Rust, so - I wish you success in doing that. ... however... > code patterns that are fine in Rust due to the borrow checker, would be footguns in languages like C or C++, That "dig" is probably not true. Or rather, your very conflation of C and C++ suggests that you are talking about the kind of…

Tell me you don't have rust experience without telling me you don't have rust experience.

Re: Wild – A fast linker for Linux

#166

Post by panstromek »

panstromek wrote: post #165
einpoklum wrote: post #164

Earlier quoted context omitted.

Rust is a perfectly fine language, and there's no reason you should not be able to implement fast incremental linking using Rust, so - I wish you success in doing that. ... however... > code patterns that are fine in Rust due to the borrow checker, would be footguns in languages like C or C++, That "dig" is probably not true. Or rather, your very conflation of C and C++ suggests that you are talking about the kind of…

Tell me you don't have rust experience without telling me you don't have rust experience.

I mean, sorry for the snark but really, there's so many of these things that it's just ridiculous to even attempt to compare. e.g. I wouln't ever use something like string_view or span unless the code is absolutely performance critical. There's a lot of defensive copying in C(++), because all the risks of losing track of pointers are just not worth it. In Rust, you can go really wild with this, there's no comparison.

Re: Wild – A fast linker for Linux

#167

Post by mistercheph »

Defletter wrote: post #159
jenadine wrote: post #146

Earlier quoted context omitted.

It’s their loss

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.

Re: Wild – A fast linker for Linux

#168

Post by zik »

pjmlp wrote: post #89
estebank wrote: post #44

Earlier quoted context omitted.

Note that Mold has no interest in becoming incremental, so there is a big reason there for another linker to exist. I find it kind of embarrassing that MS' linker has been incremental by default for decades, yet there's no production ready incremental linker on Linux yet.

Additionally the way precompiled headers are handled in Visual C++ and C++ Builder have always been much better than traditional UNIX compilers, and now we have modules as well.

The way precompiled headers work in C++ is a bit of an ugly hack. And worse, it's almost as slow as just compiling them all every time anyway.

Re: Wild – A fast linker for Linux

#169

Post by pjmlp »

zik wrote: post #168
pjmlp wrote: post #89

Earlier quoted context omitted.

Additionally the way precompiled headers are handled in Visual C++ and C++ Builder have always been much better than traditional UNIX compilers, and now we have modules as well.

The way precompiled headers work in C++ is a bit of an ugly hack. And worse, it's almost as slow as just compiling them all every time anyway.

Only in traditional UNIX, which I mentioned.

Borland and Microsoft compilers have been dealing with them just fine since at very least 1994, when I started using Turbo C++ 3.1 for Windows.

Re: Wild – A fast linker for Linux

#170

Post by rocqua »

eredengrin wrote: post #152
yellowapple wrote: post #141

Earlier quoted context omitted.

That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.

It's not that uncommon of a convention to strictly use signed numbers unless doing bit manipulation, eg the Google C++ Style Guide.

Notably, unsigned integers also have defined behavior for overflow. This means compilers can do less optimization on unsigned integers. For example, they can't assume that. x + 1 > x for unsigned ints, but are free to assume that for standard ints.

That is just another reason to stick with signed ints unless there is a very specific behavior you rely on.

Post reply on HN