Hooking a BBC Master up as a serial terminal to browse the web again Sometime around 2010, while I was working at Google, I came up with a fun mini project to marry my love of retro computing with my excitement for working at big G. I smuggled my BBC Master into the office and hooked it up over a serial cable to my work desktop, and then after some jiggery-pokery, was able to get a terminal emulat

A tour of the AWS services behind every Compiler Explorer compilation Written with LLM assistance. Details at end. I've been meaning to write an update on how Compiler Explorer actually runs on Amazon's cloud, and it's been sat on my list for a good while now, somewhere behind the other random things that take up what laughably I refer to as my spare time 1 . The last time I wrote about this was 2

An AI interview about explaining hard things simply, conducted on a dog walk Written with LLM assistance. The interview format is genuine; the prose is lightly tidied from voice notes. I had lunch with a pal yesterday, and we got onto the subject of why so much technical material is either accurate-but-impenetrable or polished-but-slightly-wrong. It's a gap I think about a lot, partly because I ma

What has this year all been about, eh? Written by me, proof-read by an LLM. Details at end. 2025 has been quite a year for me. The big ticket things for me were having the majority of the year on a non-compete, a new job, and some videos and conference talks. It was a bumper year for my public talks, which included: ACCU Keynote - Teaching an Old Dog New Tricks C++ on Sea - a reprise of the above

The end of the 2025 Advent of Compiler Optimisation Written by me, proof-read by an LLM. Details at end. It's the 25th! Whatever you celebrate this time of year, I wish you the very best and hope you are having a lovely day. For me, this is a family time: I'm not at all religious but was brought up to celebrate Christmas. So, today we'll be cooking a massive roast dinner and enjoying family time 1

Sometimes compilers can surprise and delight even a jaded old engineer like me Written by me, proof-read by an LLM. Details at end. Every now and then a compiler will surprise me with a really smart trick. When I first saw this optimisation I could hardly believe it. I was looking at loop optimisation, and wrote something like this simple function that sums all the numbers up to a given value: So

Taking a look at the various ways the compiler can optimise switch statements Written by me, proof-read by an LLM. Details at end. The standard wisdom is that switch statements compile to jump tables. And they do - when the compiler can't find something cleverer to do instead. Let's start with a really simple example: Here the compiler has spotted the relationship between x and the return value, a

We learn that compilers have tricks to access memory efficiently Written by me, proof-read by an LLM. Details at end. After exploring SIMD vectorisation over the last couple of days , let's shift gears to look at another class of compiler cleverness: memory access patterns. String comparisons seem straightforward enough - check the length, compare the bytes, done. But watch what Clang does when co

Why floating point maths doesn't vectorise like integers, and what to do about it Written by me, proof-read by an LLM. Details at end. Yesterday we saw SIMD work beautifully with integers. But floating point has a surprise in store. Let's try summing an array 1 : Looking at the core loop, the compiler has pulled off a clever trick: .L2: ; pick up 8 integers and add them element-wise to ymm0 vpaddd

Doing more with less: vectorising can speed your code up 8x or more! Written by me, proof-read by an LLM. Details at end. It's time to look at one of the most sophisticated optimisations compilers can do: autovectorisation. Most "big data" style problems boil down to "do this maths to huge arrays", and the limiting factor isn't the maths itself, but the feeding of instructions to the CPU, along wi

The art of not (directly) coming back: tail call optimisation Written by me, proof-read by an LLM. Details at end. Inlining is fantastic, as we've seen recently . There's a place it surely can't help though: recursion! If we call our own function, then surely we can't inline... Let's see what the compiler does with the classic recursive "greatest common divisor" routine - surely it can't avoid cal

Written by me, proof-read by an LLM. Details at end. We've learned how important inlining is to optimisation, but also that it might sometimes cause code bloat. Inlining doesn't have to be all-or-nothing! Let's look at a simple function that has a fast path and slow path; and then see how the compiler handles it 1 . In this example we have some process function that has a really trivial fast case

Copy paste can sometimes be a good thing, at least if the compiler does it for you Written by me, proof-read by an LLM. Details at end. Sixteen days in, and I've been dancing around what many consider the fundamental compiler optimisation: inlining. Not because it's complicated - quite the opposite! - but because inlining is less interesting for what it does (copy-paste code), and more interesting

Knowing how compilers call functions can help with design - and optimisation Written by me, proof-read by an LLM. Details at end. Today we're looking at calling conventions 1 - which aren't purely optimisation related but are important to understand. The calling convention is part of the ABI (Application Binary Interface), and varies from architecture to architecture and even OS to OS. Today I'll

Knowing when the compiler can't optimise is important too Written by me, proof-read by an LLM. Details at end. Yesterday we ended on a bit of a downer: aliasing stopped optimisations dead in their tracks. I know this is supposed to be the Advent of Compiler Optimisations , not the Advent of Compiler Giving Up ! Knowing why your compiler can't optimise is just as important as knowing all the clever

When aliasing can prevent loop-invariant code motion Written by me, proof-read by an LLM. Details at end. Yesterday's LICM post ended with the compiler pulling invariants like size() and get_range out of our loop - clean assembly, great performance. Job done, right? Not quite. Let's see how that optimisation can disappear. Let's say you had a const char * 1 , and wanted to write a function to retu

The compiler can move code outside of loops to speed things up Written by me, proof-read by an LLM. Details at end. Look back at our simple loop example - there's an optimisation I completely glossed over. Let me show you what I mean: On every loop iteration we are calling vec.size() to compare the index value, and to check if the index has reached the end of the vector. However, looking in the as

Duplicating loops around can yield some decent optimisations Written by me, proof-read by an LLM. Details at end. Sometimes the compiler decides the best way to optimise your loop is to... write it twice. Sounds counterintuitive? Let's change our sum example from before to optionally return a sum-of-squares 1 : At -O2 the compiler turns the ternary into: sum += value * (squared ? value : 1); - usi

Compilers can take advantage of some very specific instructions Written by me, proof-read by an LLM. Details at end. Who among us hasn't looked at a number and wondered, "How many one bits are in there?" No? Just me then? Actually, this "population count" operation can be pretty useful in some cases like data compression algorithms, cryptography, chess, error correction , and sparse matrix represe

Learning when the compiler decides to unroll loops for performance Written by me, proof-read by an LLM. Details at end. A common theme for helping the compiler optimise is to give it as much information as possible. Using the right signedness of types , targeting the right CPU model, keeping loop iterations independent , and for today's topic: telling it how many loop iterations there are going to