Current state of MIR vs QBE?

[rempas]

First of all, sorry if this is annoying! In my eyes, this is a classic question. It's like "GCC vs Clang", "Linux vs Windows", "C++ vs D", "Barcelona vs Real Madrid" etc. and it will never stop been asked (and for a good reason). I think that QBE is the only other IR that can compete with MIR (at least from the ones I know and excluding "Vox" as it doesn't have some things that I need) so this question is very important and it has to be reviewed every couple of months. Especially now, it doesn't help that there are no benchmarks against QBE but only against other C compilers. So I really believe that we need official benchmarks against QBE to be taken at least once!

Now, I want to make 2 things clear!

1. I'm not just asking out of curiosity (not that this would be bad of course) but because I am searching for the best possible backend for my language NOW. Not in the future, I'm building the compiler and based on my calculations, I'll be able to create something small in a few weeks (and I would have already made it if I wasn't very obsessed with optimize it from the start!) so I need to pick one and I don't have much time left...
2. I have tried to compare them myself but I wasn't able to compile the source code of "tcc" using "c2m". Of course, "c2m" is not part of the "libmir" but still, I thought about making comparisons in big projects that are written in C so I thought about using "c2m" and "cproc" but unfortunately, this didn't went as planned...

Now that I'm clear, the thing is pretty clear. How does MIR compares with QBE? I'm talking about compilation times, runtime performance of the output, features of the library, ease of use and in general, any comparison that can be made between them.

For what I can see myself, QBE (cproc) seems to truly compile very fast and it indeed seems to have at least 70% of "GCC -O2" runtime performance as it claims, it's IR also seems pretty easy and straightforward. Both projects seem to not be very active (at least based on how often commits are uploaded), MIR has more backends (wow!!!). And.... this is all I know!

Thank you for your time regardless! Keep up the amazing work!

[vnmakarov]

Now that I'm clear, the thing is pretty clear. How does MIR compares with QBE? I'm talking about compilation times, runtime performance of the output, features of the library, ease of use and in general, any comparison that can be made between them.

There is a performance comparison of many C compilers on small benchmarks in my blogpost
https://developers.redhat.com/blog/2021/04/27/the-mir-c-interpreter-and-just-in-time-jit-compiler#how_the_mir_c_compiler_compares_with_other_c_compilers

Basically cproc with QBE generates 20% slower code than c2m with MIR. And c2m compilation speed is 1.5 times faster than cproc one. I have no numbers of speed of MIR vs QBE itself though.

You can run these benchmarks by yourself if you have cproc in your PATH

mir/c-benchmarks/run-benchmarks.sh

Line 93 in 761fc31

if cproc $tempc >/dev/null 2>&1; then

For what I can see myself, QBE (cproc) seems to truly compile very fast and it indeed seems to have at least 70% of "GCC -O2" runtime performance as it claims, it's IR also seems pretty easy and straightforward. Both projects seem to not be very active (at least based on how often commits are uploaded), MIR has more backends (wow!!!). And.... this is all I know!

QBE does not support long double as I know. I am not sure QBE is ABI compatible even besides long double part.

I am still actively working on MIR. GITHUB shows changes only for master branch therefore MIR looks like stalled. But I am doing most my work on bbv branch. This branch will be the base for the next MIR release and I am planning to make at least one release this year. The branch is not release ready but I am using it for my work on MIR-based JIT for CRuby.

Thank you for your time regardless! Keep up the amazing work!

Thank you for your kind words.

[vnmakarov]

Should I use master or bbv? Of course, bbv is not consider a "stable release" channel but still, every commit is tested (right?) so I suppose it is safe. Other than that, are there any other reasons to not consider using it?

Sorry for delay with the answer. I recommend to use master. bbv branch is not stable and has some known bugs of new features (e.g. in register variables and anti-alias attribute usage) and how to solve the bugs still needs some thinking for me. You can switch to bbv later if you need really new features and probably a better generated code.

[rempas]

Thank you! Good luck and have fun!

[rempas]

You can switch to bbv later if you need really new features and probably a better generated code.

@vnmakarov Hello! I was thinking about some stuff and while I was working, the sentence I quoted crossed my mind.
What do you mean "better generated code"? Better in what?

[vnmakarov]

What do you mean "better generated code"? Better in what?
It means performance. The branch contains optimizations which help to improve JITted code for stack based VMs and specifically CRuby VM.

For example, the branch contains optimizations which remove redundant loads/stores. The branch implements register variables (variables which use fixed hard regs) and C extension to describe this. It also implements calls and returns by jumps and C builtins for this (which is important for direct switching to direct threaded interpreter). builtin_expect is also implemented on the branch to generate better code locality. The branch also implements anti-alias attributes to differ pointers whose values are never intersected (but it is buggy right now).

[rempas]

Wow! I just don't know what to say! You're doing MORE optimizations?! And again, the super crazy compile times! I'm really speechless! I did tried to learn how machine instruction syntax works for the fun of it and it is hell!!! (at least for x86-64) I cannot imagine that you are doing this and you are even doing optimizations that can get close to the BEAST called GCC. Your little gem deserves a great language frontend and I'm working as hard as I can to make one!

And how knows, maybe you'll want to re-write MIR on in if you end up liking it! 🤣