This is by no means scientific, but it’s a fun benchmark, there’s some debate about the fastest Rust options submitted (ie I believe there were faster than C versions that were rejected).
C and Rust have been trading blows on the language benchmark games for a while now which dictates the algorithm used. From my experience, it's relatively easy to accidentally write fast Rust, but incredibly hard to write fast C.
This is awesome! Except for a couple of benchmarks, Rust seems comparable to C and C++ in speed. I wonder if something could be done for those outlying benchmarks (of course).
There are actually cases where Rust is faster than C already, one of the reasons being the compiler emitting better code thanks to mutable aliasing being forbidden.
I love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1].
Regarding performance, the opposite side of your question is as relevant, how many optimization opportunities would have been skipped because the C API is too hard to guarantee correct usage [1]? Rust has already surpassed C on the benchmark game, can that be used as data points?
Nearly?
Rust is already faster than C in quite a few scenarios and benchmarks. The other comment also said Rust is faster when C is compiled through clang.
reply