← Back to context

Comment by MaxBarraclough

10 days ago

> That's a big gap

I wouldn't say so. The gap between GCC and Clang/LLVM is bigger than that on some benchmarks, [0] although the gap between their overall performance (using geometric mean) is much less. [1]

It's a very impressive result considering how much effort has gone into GCC. It highlights how compiler optimisation work can face diminishing returns.

> the norm for releases being O2 if I understand correctly

Agreed, but the difference isn't that great. From the article:

> CompCert code is 7% slower than gcc-01 and 12% slower than gcc-02 on average.

Reminds me of how the cproc/qbe C compiler gets very roughly 50% of the performance of Clang/LLVM in 0.1% the lines-of-code. [2]

[0] https://www.phoronix.com/review/gcc-16-vs-clang-22/3

[1] https://www.phoronix.com/review/gcc-16-vs-clang-22/6

[2] https://drewdevault.com/talks/qbe/ (and see the linked slideshow PDF, as the abstract is a little misleading)

Maybe we just have different experiences, but I've experienced a huge amount of friction trying to enable features that cost something resembling 0.5% of fleet performance, even when they provide massive benefits. 12% loss would be laughed out of the room.

I agree that this is an impressive feat. I also don't see why an equivalent for rust would be adopted.

  • > I've experienced a huge amount of friction trying to enable features that cost something resembling 0.5% of fleet performance, even when they provide massive benefits. 12% loss would be laughed out of the room.

    A 12% difference in performance between two compilers, for some given application, is possible even between two of the best optimising compilers available. A 12% performance lag does not necessarily relegate a compiler to obscurity.

    The long-entrenched MSVC compiler is still a major player despite that, for at least some applications and for at least some compiler versions, Clang outperforms it by far more than 12%. [0][1]

    If a new Rust compiler really could offer significantly fewer compiler bugs, that would of course need to be weighed against any performance penalty, and the proper tradeoff would of course depend on the project.

    > I agree that this is an impressive feat. I also don't see why an equivalent for rust would be adopted.

    I imagine it wouldn't be widely adopted for most applications. CompCert itself is pretty niche. It's not Free and Open Source software, which I suspect is a factor, alongside its technical drawbacks.

    Unless you're working on ultra-low-defect software, such as in a safety-critical domain, compiler bugs are unlikely to be a major factor in your software's quality. If the compiler lacks support for interesting language features, it becomes an even harder sell for 'ordinary' projects that are able to tolerate an ordinary number of compiler bugs.

    [0] https://lemire.me/blog/2023/02/27/visual-studio-versus-clang...

    [1] https://discuss.python.org/t/using-clang-cl-for-better-perfo...