I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.
- to map cleanly with what compilers know to optimize best
- fine control over stack and heap allocation
- has intrinsics / assembly escape hatch
- allows you to specify that pointers don't alias (restrict in C, or default in Fortran)
- gives you prefetching primitives
You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance).
Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all):
And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.
Why not?
For instance, with current hardware, the good use of SIMD is critical. If you can't write vectorized code in (standard) C while you can do it in another Language, that would be a "faster" language.
Same for other language features that enable faster code: Compile-time computations, better memory model with different pointer aliasing semantic, ...
Yea. It's always funny when people say C is faster than Fortran for scientific computing. I mean, it's true, but only for a very limited amount of people who want to do serious numeric work. C/C++ certainly aren't rare in this area, but Fortran is pleasant to work with for most numeric work and has lots of helpful built-ins and runs close to C in speed.
- to map cleanly with what compilers know to optimize best
- fine control over stack and heap allocation
- has intrinsics / assembly escape hatch
- allows you to specify that pointers don't alias (restrict in C, or default in Fortran)
- gives you prefetching primitives
You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance).
Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all):
bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g...
code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primit...
And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.