djwatson24

I’ve always wondered about linear scan vs SSA based spilling & regalloc, like libfirm & qbe use:

‘Register spilling and live-range splitting for SSA-form programs’ and ‘Preference-Guided Register Assignment’

It’s much cleaner to code, since you don’t need to generate live ranges explicitly, and can break it up in two passes. Linear scan creates new inactive /active intervals, while the ssa form allocators just reuse the ssa graph. I’ve never benchmarked them back to back though.

> We wanted to check out the infamous Infinite Loop too, but were afraid it could take a long time.

Haha! Nerd jokes are the best jokes

It's quite impressive they're able to take nearly arbitrary C and do this! Very similar to what pypy is doing here, but for C, and not a python subset.

However not without downsides. It sounds like average code is only 2x faster than Lua, vs. LuaJit which is often 5-10x faster.

Absolutely. Things that took hours or days to debug before take mere minutes once I have an rr recording.

Tail calling (with musttail)+ preserve_none are definitely the future of interpreters. Gets you ~95% of the performance of writing the vm in assembly, while keeping it high level. Unfortunately only clang and llvm support it so far, but hopefully we get some other llvm backend langs in soon!

Can you go in to more detail on 'wacky register allocation tricks' or instruction selection needed to support nun-tagging? Or pointers to code somewhere? Would be nice to compare some of them to the paper.

Deegen is my research meta-compiler to make high-performance VMs easier to write. Deegen takes in a semantic description of the VM bytecodes in C++, and use it as the single source of truth to automatically generate a high-performance VM at build time

This is great, thanks! Fyi I think you have the numbers for the years reversed

> and that relies on having sufficient test and fuzz coverage

At the faang I worked at, some small portion of servers ran the sanitizers in prod, so you’re not reliant on test coverage nearly so much for catching rare issues.

Binary trees is a classic GC benchmark - ideally a GC'd language should be able to do better than a malloc/free implementation in C (tree.c) since it can release the whole tree in bulk (like what the ptree.c does).

Also note that tree.c speeds up substantially if you link with a better malloc like jemalloc or tcmalloc.

I agree the optimization looks backwards to me - in most of the microcontrollers I work on, the flash program space can easily be multiple megabytes, but the ram is usually the limiter around 128-512k.

D has three fully functional compilers on Linux, and is probably in better shape than python, rust, even c++ in that regard.