The real issue is actually runtime ELF (and PE) which are obsolete on modern hardware architecture.
What do you mean by this?
Wild – A fast linker for Linux
71–80 of 222 posts
Re: Wild – A fast linker for Linux
#72That looks promising. In Rust to begin with and with the goal of being fast and support incremental linking. To use it with Rust, this can probbaly also work using gcc as linker driver. In project's .cargo/config.toml: [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-fuse-ld=wild"] Side note, but why does Rust need to plug into gcc or clang for that? Some missing functionality?
Because Rust compiler generates IR bytecode, not machine code.
Re: Wild – A fast linker for Linux
#73What 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…
[flagged]
>Secondly, if you think any compiler is meaningfully doing anything optimal >>("whole program analysis") on a TU scale greater than say ~50kloc (ie ~10 files) >relative to compiling individually you're dreaming.
That's wrong. gcc generates summaries of function properties and propagate those up and down the call tree, which for LTO is then build in a distributed way. It does much more than mere inlining, but even advanced analysis like points to analysis.
https://gcc.gnu.org/onlinedocs/gccint/IPA.html https://gcc.gnu.org/onlinedocs/gccint/IPA-passes.html
It scales to millions of lines of code because it's partioned.
Re: Wild – A fast linker for Linux
#74Ever 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.
Wait a minute, it’s possible to relicense something from GPL to MIT?
Re: Wild – A fast linker for Linux
#75Ever 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.
Wait a minute, it’s possible to relicense something from GPL to MIT?
Yes. Generally you need permissions from contributors (either asking them directly or requiring a contribution agreement that assigns copyright for contributions to either the author or the org hosting the project), but you can relicense from any license to any other license.
That doesn't extinguish the prior versions under the prior license, but it does allow a project to change its license.
Re: Wild – A fast linker for Linux
#76Earlier 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.
[flagged]
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
Re: Wild – A fast linker for Linux
#77I 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…
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.
Re: Wild – A fast linker for Linux
#78That looks promising. In Rust to begin with and with the goal of being fast and support incremental linking. To use it with Rust, this can probbaly also work using gcc as linker driver. In project's .cargo/config.toml: [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "link-arg=-fuse-ld=wild"] Side note, but why does Rust need to plug into gcc or clang for that? Some missing functionality?
Because Rust compiler generates IR bytecode, not machine code.
That's the reason to use llvm as part of Rust compiler toolchain, not to use gcc or clang as linker manager?
Re: Wild – A fast linker for Linux
#79> Mold is already very fast, however it doesn't do incremental linking and the author has stated that they don't intend to. Wild doesn't do incremental linking yet, but that is the end-goal. By writing Wild in Rust, it's hoped that the complexity of incremental linking will be achievable. Can someone explain what is so special about Rust for this?
Apart from what others said, maybe he plans to use Salsa or something like that. Rust has a few popular libraries for doing this.
Re: Wild – A fast linker for Linux
#80Earlier 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.
If you're debugging, and your bug only reproduces with LTO enabled, you don't have much of a choice...