4 ms·

tcc is popular too, as a fast non-optimizing compiler.

• cenamus 2y ago
  Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
  • mananaysiempre 2y ago
    The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.) [1] https://briancallahan.net/blog/20211010.html https://briancallahan.net/blog/20211010.html
    • cenamus 2y ago
      Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
      • mananaysiempre 2y ago
        Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.
        • fuhsnn 2y ago
          I tested with tcc, cparser and my own slimcc, the benchmark showed multiple process with htop, so there are some dynamic cpu scaling randomness going on. I saw larger run-to-run differences with the same binary, than with comparing cherry-picked best-run of each, so probably not the best benchmark.
• usr1106 2y ago
  Fabrice Bellard, unbelievable what a single person can get done.