Speed of Rust vs. C
kornel.ski
kornel.ski
Really glad to see this mentioned, I search for it in every post like this.
LLVM should follow now that the mutable noalias bugs appear to be fixed. Remember when it was a meme that every time it gets enabled in rustc, it has to be disabled again in the next x.y.1 release? It's been left enabled for years.
The biggest challenge here is that most people aren't looking for optimizations beyond what they were already getting with C. Like when Google was switching from GCC to Clang, they'd pick apart the asm and report bugs for Clang and LLVM to converge on GCC. That was a big part of why the performance gap closed over the years. But that was closing a gap, not speculatively overtaking them.
Then there's a whole other angle; we now know just how much machine code layout can affect real-world performance, in most cases much more than aliasing rules, but we still haven't made it a seamless part of our build tooling. PGO is now fairly easy, but BOLT is still a pain to integrate for no clear reason, and PROPELLER has been left in an embarrassing state where even its own PDF link is broken [1][2].
[1] https://github.com/google/llvm-propeller
[2] To be fair, it may not be Google's highest priority at this time.
That was a funny one!
Edit: after reading the whole article, I found it very useful; it contains lots of information about parallelism both on C and Rust. I would say it is excellent for a beginner in that stuff.
Amen to that. The inconvenience of the borrow checker is amortized very quickly.
What if you only need to access higher-level interfaces for basic parallel and concurrent operations? You hardly need a language that is written around a particular memory management strategy if all you need to do is queue a message.
619 points | 525 comments
You often end up with e.g. `String`, especially in async libraries that need `:Send+Sync+'static` so lifetimes are right out. Now you can't avoid allocations and copies, you can't even reuse a single `String` buffer because the callee takes ownership. No, `Cow` is not an option, it has a lifetime parameter and if it was 'static we're right back where we started. `Arc<str>` could arguably have been an option but I can't say I have ever seen that in a library's public API.
This kind of code isn't just slower than C, it's slower than Go where unsafe heap object sharing is the path of least resistance because there's no clone() anyway. Go doesn't even optimize CPU-bound code well, but if you use one of these APIs heavily then avoiding allocations and copies can more than make up for it. It's a big If, but it's happened to me with mature, official async libraries.
Rust the language isn't the problem here, we need better shared 'static types to land in the standard library so crates aren't afraid to put them in their API surfaces. Strings are an obvious starting point, but vectors and maps should follow.
Go is slower than C and Rust, IME, for two big reasons:
1) It puts a lot of stuff on the heap, that could've been on the stack. This wrecks locality and makes Go call malloc/free a lot. (Actually not the malloc, just a malloc.)
2) Rust and C++ offer fine control over things like dispatch, checked and unchecked casts, control for allocation, strings, etc. Go usually offers one unified thing that's simple to use. So a lot more calls are virtual, a lot more things are checked at runtime, etc.
I don't understand why garbage collection is so mythologized. TBH I don't even understand why people think `Arc` and `shared_pointer` aren't garbage collection. Is this just the effect of Swift and Rust's marketing ("look, ma, no GC")?
Because when people talk about garbage collection in the context of the dichotomy between Rust and Java or Go, they talk about the latter being automatic memory management based on various heuristics, with the related runtime overhead, non-deterministic, etc.
Whereas Rust Arc is just reference counting and explicit, not to mention enforced at compile time.
I don't understand how and why anyone would consider the two as the same thing. They are both GC in the same sense that cars and boats are both vehicles.
Now, do you really don't see how a Java/GO style GC and reference counting are different?
It's not like I didn't enumerate some characteristics that make all the difference - and that explain why people do not think of those two cases as just a single thing called "garbage collection", and also why people believe that ARC would have less overhead than a Java/GO style garbage collector.
The language and runtime specification don't say anything about GC algorithms required by compliant implementations.
* ARC is not deterministic outside of toy examples
* The runtime overhead of modern GC algorithms has a lower bound than ARC, and this has been proven formally
* Reference counting is usually atomic, so it implies other wonderfully expensive things like CPU cache flushes, memory fences, etc.
* The runtime overhead of deferred GC also happens outside of the hot path, and doesn't do unpredictable non-local things if you release a reference at an inconvenient moment
* ARC is in fact a GC strategy. E.g. obj-c has autorelease pools that postpone deletion until later, so the hot path doesn't get interrupted if reference count of something reaches zero early. These things are a spectrum.
Rust leans a lot on the borrow checker, and both Rust and C++ nudge you toward using fewer heap small allocations because it is inconvenient to use them. This is where a lot of the performance wins come from, not because reference counting somehow shaves off 20% of the program's runtime.
In fact, ARC is not only a GC strategy, it is close to being the worst possible GC strategy.
* ARCs non-determinism doesn't matter outside of contrived cases. In practical use it's as deterministic as expected.
* The runtime overhead of modern GC algorithms might have been proven formally to have a "lower bound than ARC", but like many things proven formally, it's seldom the case in practice. And this isn't also counting the memory overhead from using GC. Just like the oft-repeated "JIT can be faster than compiled because it has knowledge of the runtime" but in practice that only happens on special cases, and compiled C/C++/Rust still beats its ass.
As for the runtime overhead of deferred GC happing "outside of the hot path", and yet every domain with a GC and high load/low latency has historically suffered GC pauses, and GCs have to be reworked to ever more complex byzantine schemes to try to reduce the issue.
>*ARC is in fact a GC strategy. E.g. obj-c has autorelease pools that postpone deletion until later, so the hot path doesn't get interrupted if reference count of something reaches zero early. These things are a spectrum.
Yes, like cars and 18-wheelers are a spectrum. And C++/Rust is on the other side of that spectrum compared to Java and Go.
As soon as you use atomic counters in a multi-threaded system you can wave goodbye to your scalability too!
You think it's because ARC is a better way of managing memory, but that's false. Rust is not fast because it uses ARC, it uses ARC because Rust is fast. Rust is fast because it has a good ownership model for memory, because it encourages patterns that mostly get rid of the need to dynamically manage lots of heap objects. These qualities make it cache-friendly, among other things. What's left is generally small enough that even a poor GC strategy like ARC is good enough. A state-of-the-art GC wouldn't be worth the extra complexity in Rust. (And would probably conflict with other features.)
Go needs a state of the art GC, because it wants to hide "stack vs heap" from the programmer, and so it puts a lot of things on the heap. If it used ARC, it would be unusable.
To people who have worked on programming languages, saying "ARC is good, actually" is either a sign that you're about to present a very nuanced argument informed by decades of experience, or, more likely, that you have no idea what you're talking about.
If you're going to make a claim that lies this far outside the mainstream, I'd say the onus to present a good argument is on you, not me.
With age, I've found it good to moderate my fervor in proportion to how much I know about a subject. If people learn that you're someone who talks with confidence only about things you know, you'll have an easier time getting them to listen.
It needs, but unfortunately it doesn’t have. That category is won by Java multiple times.
This one stresses the GC quite a bit (so it doesn’t make much sense for non-managed languages that can “cheat”), and there is only Haskell as a managed language that could get ahead of Java (but it is not really apples to oranges due to the different execution model), and in other’s case it is not even close.
Go is particularly bad in this benchmark, though it sort of makes sense as it optimizes for low latency, which is fundamentally at odds with throughput.
Here's a different reading:
Apple did not add ARC to Objective-C because it was a great design, rather they failed to add a tracing GC in Objective-C 2.0 that wouldn't crash left and right due to the underlying C semantics, thus they settled with the 2nd best option, having the compiler automate Cocoa's retain/release calls (similar to VC++ extensios to deal with COM AddRef/Release).
Then sold the failure as a success, and improvement, in typical Apple's fashion.
Likwise, Swift had to adopt a similar approach if it was to stay compatible with Objective-C's runtime, otherwise it would need a complicated interop layer like .NET has with COM (RCW/CCW).
Not that is matters much outside Apple's ecosystem, though.
Apparently after the whole WinRT/UWP mess, C++ is now left for writing low level stuff, with everything else on WinUI 3.0/WinAPPSDK being done in C#.
Devil May Cry 5 on PlayStation 5 seems to be doing quite alright with Campcon's in-house fork from .NET.
So in the end, other than some corner cases where no kind of automated memory management is at all allowed, people will rather take a regular car instead of a F1.
Instead, I'll use the term "automatic dynamic lifetime determination".
In a Java-style GC, there exists code that runs at runtime to determine whether or not the lifetime of a piece of memory can be determined to have expired.
In a reference-counted system, there exists code that runs at runtime to determine whether or not the lifetime of a piece of memory can be determined to have expired.
Of course, in the latter case the "code" is just checking a single counter rather than doing fancy concurrent root-tracing, but the similarity is established, and the alternatives are clearly delineable:
1) "Automatic static lifetime determination": this is what Rust does with ownership, by statically analyzing your code and automatically inserting code to free memory at statically-determined points.
2) "Manual static lifetime determination": this is the classic C-style memory management, where the author manually inserts code to free memory at statically-determined points.
You also need to do some fancy tracing for reference counting, because when a big data structure 'dies', you need to trace it completely.
Of course, reference counting also pays the price of fiddling with its counters on every single read. So every read-only workload turns into a read-write workload.
Garbage collection has no such overhead until you start the collector. (Basically all the overhead is amortised.)
"This wrecks locality and makes Go call malloc"
it didn't make sense to me, thank you!
[1] https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-b...
But as I've said, even with PGO there is not a lot of gain compared to Rust.
If you are willing to spend time on it, you can improve Go's performance quite a lot by finding places where heap escape analysis failed, and trying to fix them. But this is extremely frustrating to do.
Another thing is interfaces and all the runtime checks Go likes to do. In C++ parlance, every interface-valued dispatch is virtual by default.
For many, Go is "fast enough". Usually it's within a factor of 2 of Rust, which puts it far ahead of the interpreted languages it's usually replacing.
I used to say this too, but after I've been writing Rust for a few years, in hindsight it feels like Go as a language is simpler, but I tend to end up with more code to maintain.
I guess the error handling leaves a bit to be desired for, and I'd say even though it's better than exceptions, I still prefer Result in Rust.
I hope that with the introduction of generics in Go, things will become simpler (I know a lot of people dislike this type of polymorphism because it feels like extra complexity, but I've always seen it as a tool to reduce complexity)
By that metric, Rust is complex. Looking at a piece of code, it could do basically anything at all. It can get rewritten by a macro, operators can be overloaded, any line of code can hide implicit magic that you have no way of knowing about.
Rust gets away with being complex by having lots of correctness checks. C++ is about as complex as Rust, but, without the correctness checks, it can be a nightmare. In Rust, it might be hard to tell what happens when you run some code, but at least you know it will be nothing terrible.
what does simple mean?
1) Simple for me, writing the code
2) Simple for you, reading the code
3) Simple for the SREs who have to operate the code
4) Simple in the sense that there aren't many abstractions
5) Easy to refactor
6) Easy to use and test (a function is simpler than a bunch of objects)
7) Simple to debug (no state is simpler than yes state)
Both Go and Rust score pretty high in aggregate on these different definitions of simple, but they get there in very different ways.
* writing # Go > Rust * reading # Rust > Go * operate # Go = Rust * abstraction count # Go >> Rust # refactoring # Rust >> Go # testing # Rust > Go # debugging # Rust >> Go
Obviously these are my own opinions, yours may differ.
The underlying theme here for me: Go is somewhat easier to write right out of the gate but significantly worse to maintain. Once Rust is written it is bulletproof. Refactoring is trivial to a degree that's hard to believe if you haven't done it.
Since code is read and maintained significantly more often than it's written… you can probably guess where I end up.
Exceptions don’t disappear randomly (no, an ‘if err’ is not error handling, and repetition just makes it prone to bugs) and they contain a stacktrace. You don’t have to grep for error messages like some caveman. It even lets you live in some Schrödinger error state where both a value and an error was returned.
Go uses a tuple for error handling. As you say the compiler can't help you avoid Schrödinger's errors. If Go instead had used something like Rust's `Result` and had given you the tools necessary for dealing with generics, then most of your objections would go away.
Good programmers know better than to confuse Go for a systems programming language.
"Good programmers know better than to confuse Go for a systems programming language."
I'm only coding for 40y years now, there is still time for me to learn that wisdom I hope.
Note: this doesn’t mean tracing GCs are slow, they are in fact faster than RC. But Rust just simply has more control over what actually happens, than a managed language.