It just fundamentally does not make sense to compare languages by comparing codegen backends. GCC and LLVM do not produce the same code for equivalent code, especially when optimizations are applied. It's an apples-to-oranges comparison.

Using Clang instead of GCC, the comparison becomes slightly better, at least for microbenchmarks that don't rely too much on libraries.

These benchmarks are still useful from a practical viewpoint - answering the question "what's the expected performance bracket of using language X in real projects today". But it doesn't say anything fundamental about the language design or even the quality of the implementation.

I know what you said. I just don't think it was interesting. If by idiomatic rust, you mean generic "unoptimized" Rust being slower than optimized C, then yeah. No shit.

On a similar note, I don't think it's worth talking about C as if the only C being written is highly optimized hand rolled assembly style of C. That's one in a thousand projects.

Now, as for the benchmarks game, you mean 3 of 6 comparisons in favor of Rust. Rust is winning the benchmarks against C there.

I had a look and the top Rust and C entries are using the same pcre2 library in regex-redux. Same for pidigits where both libraries are using GMP.

The only library difference I can see is that the C entries are using OpenMP and both Rust entries are using Rayon. Now, you could claim that using Rayon gives Rust an unfair advantage. But an entirely userland library beating an industry standard with support from compilers is not a good look for C.