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.
One ongoing complaint since I moved from wordpress to hugo around three years ago was that the theming I decided on wasn’t the best. It was dark mode only, I used a non-serif font for the blog post contents making it harder to read, and the reader mode didn’t work right either. So I’ve attempted (and most likely failed) to switch over to a light mode theme, used the lovely Alegreya font as the post font, and moved from the purplish theming to a more neutral bronzy/gold look.
I’ve long thought that Zig was an interesting programming language, potentially more interesting than Rust in many respects given that Zig seems to be targetting a more modern C-like language replacement whereas Rust firmly looks like it is trying to take C++ out back like ol' yeller. Rust is powerful, but the language is complicated, and no I’m not talking about the borrow-checker (a completely genius idea) but the language itself is vast and complex.
Last week the Burst team shook up our day-to-day schedules with the opposite of a Unity classic - the hackweek. Unity has a strong culture around taking a week or two a year (once with the whole company, maybe once with your team), to hack on something that you think might be an interesting avenue for the future of Unity. These projects have often been spun out into products or parts of products in their own right.