Constrained languages are easier to optimize
14 comments
·July 27, 2025holowoodman
But the potential of easy optimization does not mean that they will be optimized. Compilers for higher-level languages are full of broken promises around their potential. "Faster than C because we can optimize" is never really realized, except in maybe one benchmark that only works in that one exact scenario and nowhere in my code...
Ygg2
> Compilers for higher-level languages are full of broken promises
Sometimes because C is lingua franca of low level.
Some noalias optimizations Rust had didn't work in LLVM, because no one bothered using it before in C.
This goes even further to hardware. C-like null terminated string search SIMD is faster than a saner (pointer + len ) string view. So it's faster to append null to end of string view than to invoke the SIMD on string slice.
holowoodman
And here we go again with the compiler excuses.
C standards with the 'restrict' keyword to allow aliasing optimisations have been existing longer than Rust. LLVM just never bothered, despite the early claims that all the intermediate language and "more modern" compiler would enable more optimisation potential. LLVM is still slower than GCC, even in plain C.
Where is the problem to quickly null-terminate a pointer+len string and use the quick null-terminated SIMD search? Should only be 1 move slower than the native C. "Space after that string" shouldn't be a problem, since in higher-level languages, allocations can make enough room, it is higher-level after all (and you need null-termination for syscalls anyways).
It is always the same story. Compiler and programming language people make claims about future optimisations but never ever follow through. It's always just theory, never implementation.
Ygg2
> LLVM just never bothered, despite the early claims that all the intermediate language and "more modern" compiler would enable more optimisation potential.
They did bother but no one seemed to be using it, so a bug snuck in. It took Rust exercising that corner of LLVM to find the bug.
> LLVM is still slower than GCC, even in plain C.
Citation needed. Last time I checked LLVM beat GCC on -O3. Unless you mean compilation performance.
> Where is the problem to quickly null-terminate a pointer+len string and use the quick null-terminated SIMD search?
Why should two nearly idenfical operations have such wildly different performance? And why isn't the safer/saner interface more performant?
My point if compilers and hardware are optimizing for C, it's no surprise no one can approach its speed.
It's like asking why when everyone is optimizing for Chrome no other web browser can approach its speed.
donatj
They are also easier to statically analyze and write tooling around.
holowoodman
Then were is my easy Haskell tooling to find the place where I should put a strictness hint? Where is the equivalent of kcachegrind?
That it's supposedly easier might be true. But that usually doesn't lead to someone really doing it.
habibur
Brings back nostalgic memories from Java days in the 2000s. "Java will be faster than C" for exactly the same reasons laid out in the article.
And here we are, 20 years later.
carlmr
I dunno, I was there in the 2000s and can't remember anyone saying that. I remember a lot of people saying Java's slightly slower execution will not matter that much when processing hardware gets better.
holowoodman
There were tons of people making those claims. https://stackoverflow.com/questions/64582/c-java-performance...
Especially profile-guided-optimization was hailed as the next big thing, only JIT-ed languages were the ones to be fast, because after some warmup time they would adapt to your data and hardware. Java is still dog-slow...
Sesse__
I was there in the 2000s and remember several people saying that.
withoutboats3
Initial comments as I write this are all negative, and also responding to something the blog post didn't claim. The only time it says faster than C is when talking about a language targeting the GPU; it is not controversial that GPUs perform better than CPUs for many workloads.
On the other hand, the results of this true fact are already seen in practice in real systems. Rust's iterator adapters, for example, allow high level "functional style" with closures to be compiled to code that is exactly the same as hand rolled C loops without unamortized bounds checks - despite guaranteeing the absence of out of bound accesses even in the face of programmer error - because the constraints of these interfaces and the design of the language enable tons of optimizations by LLVM. This has been true since Rust 1.0 more than a decade ago, it's not a promise of the future.
This is just one aspect of the principle of least power:
https://www.w3.org/DesignIssues/Principles.html#PLP
By restricting the power of a language, you enable it to be used in more ways than just “execute it and see what the result is”.