3 ms·
> There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark
by yholio 8y ago
> There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily.
So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.
- staticassertion 8y agoNot really, no. His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++. He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++. This is misleading or incorrect for a few reasons. * Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date) * The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD. * His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code" As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.
- achamayou 8y agoRust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).