3 ms·
To answer the headline: No. Rust is not faster than C. C isn't faster than Rust either. What is fast is writing code with zero abstractions or zero cost abstra
by lionkor 9mo ago
To answer the headline: No. Rust is not faster than C. C isn't faster than Rust either.
What is fast is writing code with zero abstractions or zero cost abstractions, and if you can't do that (because writing assembly sucks), get as close as possible.
Each layer you pile on adds abstraction. I've never had issues optimizing and profiling C code -- the tooling is excellent and the optimizations make sense. Get into Rust profiling and opimization and you're already in the weeds.
Want it fast? Turn off the runtime checks by calling unsafe code. From there, you can hope and pray like with most LLVM compiled languages.
If you want a stupid fast interpreter in C, you do computed goto, write a comment explaining why its not, in fact, cursed, and you're done. In C++, Rust, etc. you'll sit there examining the generated code to see if the heuristics detected something that ends up not generating effectively-computed-goto-code.
Not to mention panics, which are needed but also have branching overhead.
The only thing that is faster in Rust by default is probably math: You have so many more errors and warnings which avoid overflows, casts, etc. that you didn't mean to do. That makes a small difference.
I love Rust. If I want pure speed, I write unsafe Rust, not C. But it's not going to be as fast as trivial C code by default, because the tradeoffs fundamentally differ: Rust is safe by default, and C is efficient by default.
The article makes some of the same points but it doesn't read like the author has spent weeks in a profiler combing over machine code to optimize Rust code. Sadly I have, and I'm not getting that time back.
- steveklabnik 9mo ago> Want it fast? Turn off the runtime checks by calling unsafe code. You can do that for sure, but you can also sometimes write your code in a different way. https://davidlattimore.github.io/posts/2025/09/02/rustforge-wild-performance-tricks.html https://davidlattimore.github.io/posts/2025/09/02/rustforge-... is an interesting collection of these. > it doesn't read like the author has spent weeks in a profiler combing over machine code to optimize Rust code It is true that this blog post was not intended to be a comprehensive comparison of the ways in which Rust and C differ in performance. It was meant to be a higher level discussion on the nature of the question itself, using a few examples to try and draw out interesting aspects of that comparison.
- michalsustr 9mo agoWhat are your favorite tools for profiling/optimizing C and Rust code?
- lionkor 9mo agoDefinitely the combination of callgrind (valgrind --tool=callgrind) and kcachegrind, or the combination of HotSpot and perf. I have toyed with Intel's vTune, but I felt it was very hard to get running so its discouraging before you even start. That said, if you need a lot of info on cache etc., vTune is fantastic.
- michalsustr 9mo agoThank you! :)
- aw1621107 9mo ago> If you want a stupid fast interpreter in C, you do computed goto, write a comment explaining why its not, in fact, cursed, and you're done. Bit of an aside, but these days it might be worth experimenting with tail call interpreters coupled with `musttail` annotations. CPython saw performance improvements over their computed goto interpreters with this method, for example [0]. [0]: https://lwn.net/Articles/1010905/ https://lwn.net/Articles/1010905/