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

171–180 of 222 posts

Re: Wild – A fast linker for Linux

#171

Post by CaptainOfCoit »

LeFantome wrote: post #113
mrighele wrote: post #110

Earlier quoted context omitted.

That depends on how old and big is the project. For example Linux is "stuck" on GPL2 and even if they wanted to move to something else it wouldn't be feasible to get permission from all the people involved. Some contributors passed away making it even more difficult.

Not exactly “stuck” since they very explicitly do not want to move to GPL 3.

Even if they wanted to move to another license (which they don't), they wouldn't be able to do. So sounds exactly like they're "stuck", regardless of what they want.

Re: Wild – A fast linker for Linux

#172

Post by leeoniya »

miki123211 wrote: post #155
leeoniya wrote: post #134

Earlier quoted context omitted.

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…

might have been a problem in Bun that was fixed by: https://github.com/oven-sh/bun/pull/16747

Re: Wild – A fast linker for Linux

#173

Post by wyldfire »

pwdisswordfishz wrote: post #154
zelcon wrote: post #135

Earlier quoted context omitted.

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.

They do if they're AGPL licensed and the internal form software is used to provide a user facing service.

Re: Wild – A fast linker for Linux

#175

Post by cies »

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?

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 seen as one of the strategies to make money off FLOSS.

Re: Wild – A fast linker for Linux

#176

Post by p_ing »

berti wrote: post #143
leeoniya wrote: post #134

Earlier quoted context omitted.

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

That’s exactly the problem “Dev Drive” is intended to solve I believe. I haven’t tried it myself. https://learn.microsoft.com/en-us/windows/dev-drive/

It helps. Install your games on it, too.

Re: Wild – A fast linker for Linux

#177

Post by kibwen »

einpoklum wrote: post #158
o11c wrote: post #148

Earlier quoted context omitted.

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

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 simple linkers that don't support linker scripts, and the other poor souls can keep using ld.

Re: Wild – A fast linker for Linux

#178

Post by yosefk »

pjmlp wrote: post #91
ComputerGuru wrote: post #13

There’s been a lot of interest in faster linkers spurred by the adoption and popularity of rust. Even modest statically linked rust binaries can take a couple of minutes in the link stage of compilation in release mode (using mold). It’s not a rust-specific issue but an amalgam of (usually) strictly static linking, advanced link-time optimizations enabled by llvm like LTO and bolt, and a general dissatisfaction with…

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

Re: Wild – A fast linker for Linux

#179

Post by bjourne »

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…

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.

Re: Wild – A fast linker for Linux

#180

Post by einpoklum »

panstromek wrote: post #166
panstromek wrote: post #165

Earlier quoted context omitted.

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.

> because all the risks of losing track of pointers are just not worth it.

These risks are mostly, and often entirely, gone when you write modern C++. You don't lose track of them, because you don't track them, and you only use them when you don't need to track them. (Except for inside the implementations of a few data structures, which one can think of as the equivalent of unsafe code in Rust). Of course I'm generalizing here, but again, you just don't write C-style code, and you don't have those problems.

(You may have some other problems of course, C++ has many warts.)

Post reply on HN