Who cares how fast the code is, if it isn't the correct code?
Who cares how fast the code is, if it isn't the correct code?
You've broken the full employment theorem for compiler writers.
Many compiler writers are employed by hardware companies, and these companies are employing them to sell their hardware chips. For these companies, even a 1% boost in performance on $BENCHMARK can drive measurable impact on sales. Even if you're not worried about driving hardware sales, performance tends to be the major benchmark that gets mentioned in comparisons--note how the "Benchmarks Game" (what used to be called the Programming Language Shootout) compares languages solely on the basis of performance.
In other words, if you look at actual customer behavior, performance tends to be one of the most dominant factors in choosing one compiler over another (language compliance is probably more dominant, however). Surety of correctness is not a major factor at all.
Now, in order to actually report benchmarks correctly, you have to implement them correctly, so to some degree you have a basic guarantee that the compiler will usually work. But someone pointing out a soundness issue using a hypothetical example (as opposed to real code) is going to end up low priority because the evidence is that it doesn't matter in practice for the real, large applications that customers care about (as no one else has complained about it for the past several years).
In summary, practical performance will win out over theoretical correctness, but not practical correctness.
Not true.
1) source code size is compared
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
2) correctness is checked
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
3) time "to complete and log all make actions" (build the program) is also logged
This is new to me (the Benchmarks Game has been around for well over a decade).
> 2) correctness is checked
This is par for the course of benchmarks. A benchmark that is incorrectly compiled provides no useful information whatsoever about performance. It's not really what people mean when they complain about correctness issues in the compiler (which is generally referred to as soundness in literature).
> 3) time "to complete and log all make actions" (build the program) is also logged
Performance in a compiler is usually taken to be a combination of runtime, code size, and compile time, although all three components are not weighted equally.
https://web.archive.org/web/20060523195137/http://shootout.a...
https://web.archive.org/web/20060519213743/http://shootout.a...
> Performance in a compiler is usually taken to be a combination of runtime, code size, and compile time
The benchmarks game shows source code size, not compiled code size.
Unfortunely regardless of their own reports regarding CVEs, Microsoft, Apple and Google keep turning to C and C++ for their bottom layers + managed languages, instead of going full speed in some of those alternatives.
So it appears to be the long term solution to mitigate security issues, while keeping compatibility with existing code and tooling.
You are right that after having proven your code correct, you might want to use an implementation (compiler or interpreter), that is also proven correct. But those are still two different things.
But I agree that C is not the best language for writing critical code.