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

151–160 of 222 posts

Re: Wild – A fast linker for Linux

#151

Post by oguz-ismail »

o11c wrote: post #145
panzi wrote: post #133

Earlier quoted context omitted.

Why does AGPL Vs MIT matter for a linker?

Corps want to be able to release and use tools that take away the freedoms that GPL-family licenses provide. Often this results in duplication of effort. This is not theoretical; it happens quite frequently. For toolchains, in particular I'm aware of how Apple (not that they're unique in this) has "blah blah open source" downloads, but often they do not actually correspond with the binaries. And not just "not fully r…

So they donate money instead of code? The project somehow benefits from the switch to MIT?

Re: Wild – A fast linker for Linux

#152

Post by eredengrin »

yellowapple wrote: post #141
jdxcode wrote: post #119

Earlier quoted context omitted.

I totally see the point of this, but still, you have to admit this is pretty funny: > Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so…

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.

Re: Wild – A fast linker for Linux

#153

Post by oguz-ismail »

davidlattimore wrote: post #121
ndesaulniers wrote: post #90

Can it link the Linux kernel yet? Was a useful milestone for LLD.

Not yet. The Linux kernel uses linker scripts, which Wild doesn't yet support. I'd like to add support for linker scripts at some point, but it's some way down the priority list.

Does it at least support -Ttext, -Tdata, etc.?

Re: Wild – A fast linker for Linux

#154

Post by pwdisswordfishz »

zelcon wrote: post #135
panzi wrote: post #133

Earlier quoted context omitted.

Why does AGPL Vs MIT matter for a linker?

Corps don't want to have to release the source code for their internal forks. They could also potentially be sued for everything they link using it because the linked binaries could be "derivative works" according to a judge who doesn't know anything.

They don't have to release source for internal forks.

Re: Wild – A fast linker for Linux

#155

Post by miki123211 »

leeoniya wrote: post #134
cyco130 wrote: post #130

Earlier quoted context omitted.

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.

it's usually windows defender and virus scanning that causes these massive slowdowns.

And as a result of this, if you want to optimize your program to be fast on Windows, you will make very different optimization decisions than on other platforms.

For example, Windows runs virus scans on close(), which makes it very slow. This means that sometimes it makes sense to have one or more background threads exclusively dedicated to closing files.

There's a good talk on this at https://www.youtube.com/watch?v=qbKGw8MQ0i8

Re: Wild – A fast linker for Linux

#156

Post by menaerus »

davidlattimore wrote: post #94
bjourne wrote: post #86

What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.

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…

Exactly. But also even in build-from-scratch use-case when there's a multitude of binaries to be built - think 10s or 100s of (unit, integration, performance) test binaries or utilities that come along with the main release binary etc. Faster linkers giving even a modest 10% speedup per binary will quickly accumulate and will obviously scale much better.

Re: Wild – A fast linker for Linux

#157

Post by menaerus »

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…

> 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

Perhaps it is worth repeating the experiment with heavy MLoC codebases. jmalloc or mimalloc.

Re: Wild – A fast linker for Linux

#158

Post by einpoklum »

o11c wrote: post #148
ajb wrote: post #81

2008: Gold, a new linker, intended to be faster than Gnu LD 2015(?): Lld a drop in replacement linker, at least 2x as fast as Gold 2021: mold, a new linker, several times faster than lld 2025: wild, a new linker...

Rarely mentioned: all of these occur at the cost of not implementing a very large number of useful features used by real-world programs.

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)?

Re: Wild – A fast linker for Linux

#159

Post by Defletter »

jenadine wrote: post #146
mgsloan2 wrote: post #144

Earlier quoted context omitted.

See for example https://opensource.google/documentation/reference/using/agpl... > Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

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.

Re: Wild – A fast linker for Linux

#160

Post by shakna »

yellowapple wrote: post #141
jdxcode wrote: post #119

Earlier quoted context omitted.

I totally see the point of this, but still, you have to admit this is pretty funny: > Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so…

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.

The __LINE__ macro defaults to "int". That then gets handed to the debugger.
Post reply on HN