71–80 of 264 posts
A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, wh…
Earlier quoted context omitted.
For anyone who wants to form their own opinion about whether this style of programming is easier or harder than it would be in other languages: https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/token...
The tokenizer is not really a good demonstration of the differences between these styles. A more representative comparison would be the later stages that build, traverse, and manipulate tree and graph data structures.
https://github.com/rust-lang/rust/tree/1.87.0/compiler/rustc... (main logic seems to be in expr.rs)
vs
https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/Parse...
Again, for those who wish to form their own opinions.
I'd vote for filesystem space utilization to be worked on before performance.
What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?
Someone has taken up the work on this though there are some foundational steps first.
1. We need to delineate intermediate and final build artifacts so people have a clearer understanding in `target/` what has stability guarantees (implemented, awaiting stabilization).
2. We then need to re-organize the target directory from being organized by file type to being organized by crate instance.
3. We need to re-do the file locking for `target/` so when we share things, one cargo process won't lock out your entire system
4. We can then start exploring moving intermediate artifacts into a central location.
There are some caveats to this initial implementation
- To avoid cache poisoning, this will only items with immutable source that and an idempotent build, leaving out your local source and stuff that depends on build scripts and proc-macros. There is work to reduce the reliance on build scripts and proc-macros. We may also need a "trust me, this is idempotent" flag for some remaining cases.
- A new instance of a crate will be created in the cache if any dependency changes versions, reducing reuse. This becomes worse when foundation crates release frequently and when adding or updating a specific dependency, Cargo prefers to keep all existing versions, creating a very unpredictable dependency tree. Support for remote caches, especially if you can use your project's CI as a cache source, would help a lot with this.
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand li…
That doesn't sound likely. I would expect seconds unless something very odd is happing.
Is the example symbolicator?
I can't build the optional "symbolicator-crash" crate because it's not rust but 300k of C++/C pulled from a git submodule that requires dependencies I am not going to install. Your complaint might literally be about C++!
For the rest of the workspace, 60k of rust builds in 60 seconds
- clean debug build on a 6 year old 3900X (which is under load because I am working)
- time includes fetching 650 deps over a poor network and building them (the real line count of the build is likely 100s of thousands or millions of lines of code)
- subsequent release build took 100s
- I use the mold linker which is advised for faster builds
- modern cpus are so much faster than my machine they might not even take 10s
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand li…
Also, does the line of code you count include dependencies (admitting, dependencies in Rust are a problem, but it's not related to compiler performance)?
This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.
Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memo…
This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?
We looked at proposing Rust as the second blessed language in addition to Go where I work, and the conclusion was basically... why?
We have skilled Go engineers that can drop down to manual memory management and squeeze lots of extra performance out of it. And it's still dead simple when you don't need to do that or the task is suitable for a junior engineer. And channels are simply one of the best concurrency primitives out there, and baked into the language unlike Rust where everything is library making independent decisions. (to be fair I haven't tried Elixir/Erlang message passing, I understand people like that too).
This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.
But how big are your big projects?
I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability. I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.
Rust is in the process of building out the cranelift backend. Cranelift was originally built to be a JIT compiler. The hope is that this can become the debug build compiler.
Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture. Rust can likely never be rearchitected without causing a disastrous schism in the community,…
It's certainly possible to think of language features that would preclude trivially-achievable high-performance compilation. None of those language features that are present in Rust (specifically, monomorphized generics) would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.