Editors prefix: I originally penned this in September, but got cold feet that I had somehow missed something crucial in my investigations, impostor syndrome reared its head, and I binned the post. But after being involved in a tweet thread about the compressibility of these tables, I’m gonna just publish my potentially flawed work incase someone notices something obvious! Having implemented my fair share of drivers, and worked on a few languages too, one thing that has always interested me is how can we check that math functions are correct.

With the Burst compiler that I work on here at Unity, we use LLVM to produce highly performant codegen from the High Performance C# (HPC#) subset that we compile. We keep Burst actively supported all the way back to LLVM 10, so it means that I can always get an idea of the performance improvements (or regressions) that occur between LLVM versions. I’ve used a big internal project that amounts to about 2.

A nice little feature I’ve just added to my single header C/C++ unit testing library utest.h is the ability to skip a test case. The motivation for this feature is from a user request, and it makes sense in the context that sometimes you might be refactoring some code, or designing a new feature, and the tests aren’t quite ready yet. You don’t want to comment out or delete the code, so what do you do?

One of the things I was going to talk about in my COVID cancelled EuroLLVM 2020 talk was about a neat little trick we used to get the LLVM legacy pass manager to be significantly faster. So just in time for the legacy pass manager to finally sail off into the coding afterlife I thought I’d share the trick. TL;DR running less passes makes things compile faster. The longer version requires a bit more nuance though.

My single header C/C++ cross platform sub-process interaction library subprocess.h was designed using fork() on Linux/macOS. But a little birdie told me that I should be looking into using posix_spawn() instead as it was faster. TL;DR - I’ve switched the library to use POSIX spawn. There are various reasons fork can be slow, so how does my library fare? This is running on my MacBook Air (M1, 2020): process created fork() posix_spawn() % faster clang –version 322.