4 ms·
Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
by 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 agoThe 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 agoThose results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
- mananaysiempre 2y agoRight?.. 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 agoI 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.