I’ve updated my C/C++ open sources libraries utest.h, utf8.h, ubench.h, hashmap.h, subprocess.h, and json.h to use the new Apple Silicon GitHub CI runners. So how hard is it? Simple! You just add macos-14 to the build -> strategy -> matrix. I took the opportunity to drop macos-latest (which is still set to macos-13, the last x86 runner) and explicity use the oldest supported macos-11 instead. The new Apple Silicon runner is roughly 2x faster than the x86 one too - nice!
So I got my Raspberry PI 5. And like in my previous post, I compiled LLVM 17 on the Raspberry PI 5, and have compared the compile speed versus the Raspberry PI 4. I’m going to do the same steps: Compile LLVM using the default clang got via apt-get. Compile LLVM again using the clang we just built. And compile it a third time with the clang we built with our own clang (this step should be the most accurate picture of the difference in performance between the 4 and 5, because it should be the same binary compiling the same project).
With the imminent launch of the Raspberry Pi 5 I wondered - how long does it take to compile the latest LLVM release (17 at the time of writing this blog) on the Raspberry Pi 4. This will give me a baseline that I can test the Raspberry Pi 5 against once I get ahold of it. For my initial exploration I decided to test just three things: Using the stock Clang compiler I could get at via apt get to compile LLVM.
The Return to Office episode of one of my favourite podcasts Dithering made me finally decide to post about Remote Work. I’ll be back to my irregular coding posts soon, but I wanted to get this off my chest. Let me get all the caveats out the way - I worked in an office full time for the first five years of my career, and have now been working remotely for nine years.
I was looking at hardware rounding modes the other day, and one thing that I realised I had no concept of was how costly is it to change the hardware rounding mode for floating-point operations. For those that don’t know - modern hardware often includes a way to set the rounding mode that floating-point operations use when there is an imprecision in the result of a floating-point operation that cannot be encoded in the format.