Earlier quoted context omitted.
If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...
Sure, for that 1% of the time.
...which takes these remaining 99% of a development time...
Wild – A fast linker for Linux
111–120 of 222 posts
Re: Wild – A fast linker for Linux
#1122008: 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...
Gold is slated for removal from binutils for version 2.44.0, so it's officially dead.
Re: Wild – A fast linker for Linux
#113Earlier quoted context omitted.
> or if you managed to get permission from every single person who contributed This makes it sound more difficult than it actually is (logistically); it's not uncommon for major projects to require contributors to sign a CLA before accepting PRs.
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.
Re: Wild – A fast linker for Linux
#114"These benchmark were run on David Lattimore's laptop (2020 model System76 Lemur pro), which has 4 cores (8 threads) and 42 GB of RAM."
https://news.ycombinator.com/item?id=33330499
NB. This is not to suggest wild is bloated. The issue if any is the software being developed with it and the computers of those who might use such software.
Re: Wild – A fast linker for Linux
#115Earlier quoted context omitted.
I’m not sure if you’re intending to leave a negative or positive remark, or just a brief history, but the fact that people are still managing to squeeze better performance into linkers is very encouraging to me.
Certainly no intention to be negative. Not having run the numbers, I don't know if the older ones got slower over time due to more features, or the new ones are squeezing out new performance gains. I guess it's also partly that the bigger codebases scaled up so much over this period, so that there are gains to be had that weren't interesting before.
Good question, I always wonder the same thing. https://www.phoronix.com/news/Mold-Linker-2024-Performance seems to show that that the newer linkers still outperform their predecessors, even after maturing. But of course this doesn’t show the full picture.
Re: Wild – A fast linker for Linux
#116I think the optimal approach for development would be to not produce a traditional linked executable at all, but instead just place the object files in memory, and then produce a loader executable that hooks page faults in those memory areas and on-demand mmaps the relevant object elsewhere, applies relocations to it, and then moves it in place with mremap. Symbols would be resolved based on an index where only updat…
You can sort of do that with some of LLVM's JIT systems https://llvm.org/docs/JITLink.html , I'm surprised that no one has yet made a edit and continue system using it.
They have! It's called Julia and it's great.
Re: Wild – A fast linker for Linux
#117[dead]
Re: Wild – A fast linker for Linux
#118Earlier quoted context omitted.
Isn't this how dynamic linking works? If you really want to reduce build times, you should be making your hot path in the build a shared library, so you don't have to relink so long as you're not changing the interface.
But do rust’s invariants work across dynamic links? I thought a lot of its proofs were done at compile time not link time.
The proof can be done on the whole code (in memory, incremental, etc), and then the modules emitted as dynamically loadable objects.
Re: Wild – A fast linker for Linux
#119What would be refreshing would be a C/C++ compiler that did away with the intermediate step of linking and built the whole program as a unit. LTO doesn't even have to be a thing if the compiler can see the entire program in the first place. It would still have to save some build products so that incremental builds are possible, but not as object files, the compiler would need metadata to know of the origin and depend…
SQLite3 just concatenation everything together into one compilation unit. So, more people have been using this than probably know about it. https://sqlite.org/amalgamation.html
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 forth, where each file is less than 32,768 lines in length
Re: Wild – A fast linker for Linux
#120Earlier quoted context omitted.
I solved this by using Wasm. Your outer application shell calls into Wasm business logic, only the inner logic needs to get recompiled, the outer app shell doesn't even need to restart.
How is this different than dynamically linking the business logic library?
Very similar, but Wasm has additional safety properties and affordances. I am trying to get away from dynamic libs as an app extension mechanism. It is especially nice when application extension is open to end users, they won't be able to crash your application shell.
https://wasmtime.dev/ https://github.com/bytecodealliance/wasmtime