1. consistently had much faster compilation times than C++ or Rust
2. consistently generated some the smallest binaries
3. consistently ended up in #1 on programming language benchmarks
4. consistently been used to write the worlds OS kernels, where speed is critical
does not have _strong evidence_ that is going to continue to deliver better performance than C++ or Rust?
On the contrary, there is no evidence that Rust will ever be as fast as C. The burden on proof is on you and Rust to support your bold claims. C++ is in a different boat - it already tried to displace C in the 90s and it has been successful only in the environments where its other properties are a much more needed advantage, not for being faster than C. That's where Rust will end up - in between Java and C++. It will never displace C, because you pay for runtime safety with CPU cycles. Static analysis can only get you so far.
Even Java's JIT, which got everyone excited about beating C in the early 2000s, failed miraculously at being faster than C, even if it could generate better assembly code at runtime, precisely because extra features cost cycles which necessarily slow down execution speed, so you're not the first group of people with starry eyes and bold claims about performance and C.
As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs.
C has existed for a longer time, and for historical reasons it's used for some of the biggest and most popular kernels. That makes sense. However, newer kernels don't necessarily stick to C (e.g. Fuschia's kernel is in C++); there is also no evidence that kernels in C++ would be slower than the C equivalent. Regarding your other points:
1. compilation time is not related to runtime performance.
2. smaller binaries can mean better perf sometimes, but it's not always a win. It's a deep tradeoff between inlining/specialization/code size.
3. benchmarks are fun, but I think it's misleading to claim they're absolute truth. In particular, a popular benchmark will be tuned endlessly till it yields what you want. For real code you get a tradeoff between the effort put in optimization, and the total time to deliver features. I think this is where C++ (and rust) shine over C.
4. see above
For the rest: "continue to deliver better performance than C++ or Rust" that makes no sense since C++ and rust are more recent. And C++ can be just as performant as C already, or better (for a given amount of programmer effort). Code reuse is a big deal.
The runtime impact of safety features is real, but (for non-elided bound checking) it's pretty low. Rust is also known for compile-time safety features which can help writing better code because you need to spend less time on debugging; the classic examples are string handling (keeping slices of the input is easier to do safely in Rust) and threading. Some features of C++ and Rust are also better optimizable than the equivalent C idiom (e.g. to represent objects/dynamic dispatch).
Comparing C++ and Rust with java is a red herring. Java is JIT compiled and garbage collected, with little control over memory layout. People might have overhyped it in the 1990s and 2000s, sure. Rust and C++ give you as much control as C if you need it, and they go throught the same static code generator (LLVM) than one of the leading C compilers. Rust also will optimize the memory layout of structs for you by rearranging fields unless you explicitly use `#[repr(C)]`, which means that it'll be smaller than C's equivalent on average.
> As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs.
Maybe if you spend as much time to write your C hashmap as was spent on the generic Rust hashmap. That's really a long time. If you just need a hashmap somewhere, pulling the standard Rust hashmap (or, in C++, abseil, from which the Rust version took inspiration) will deliver great performance for little effort, so you can move on with your life and spend more time on the profiling phase. I think we talk too often about "absolute" performance without accounting for the total time it takes to achieve it, including debugging, profiling, etc.
1. consistently had much faster compilation times than C++ or Rust
2. consistently generated some the smallest binaries
3. consistently ended up in #1 on programming language benchmarks
4. consistently been used to write the worlds OS kernels, where speed is critical
does not have _strong evidence_ that is going to continue to deliver better performance than C++ or Rust?
On the contrary, there is no evidence that Rust will ever be as fast as C. The burden on proof is on you and Rust to support your bold claims. C++ is in a different boat - it already tried to displace C in the 90s and it has been successful only in the environments where its other properties are a much more needed advantage, not for being faster than C. That's where Rust will end up - in between Java and C++. It will never displace C, because you pay for runtime safety with CPU cycles. Static analysis can only get you so far.
Even Java's JIT, which got everyone excited about beating C in the early 2000s, failed miraculously at being faster than C, even if it could generate better assembly code at runtime, precisely because extra features cost cycles which necessarily slow down execution speed, so you're not the first group of people with starry eyes and bold claims about performance and C.
As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs.
reply