A Week in Aurora: CppCon 2026

Last year my company sent me to C++ on Sea (now ACCU on Sea) as an attendee, and I came home thinking I should try submitting a talk of my own. I gave one at C++ Online in March, remotely, and then my abstract was accepted at CppCon, so this time it was in person. The acceptance email landed on July 13th, my birthday. Not a bad present. I spent the week of September 15th in Aurora, Colorado for CppCon 2026, out of the Gaylord Rockies, there as a speaker thanks to the conference’s sponsors covering my travel and lodging, and spent two days before the show in Fedor Pikus’s High-Performance Concurrency workshop, thanks to Azul picking up the fee.

It was my first CppCon, and my first trip to the US. The Gaylord Rockies is a great hotel, and since the workshop meant getting there early, on the Friday before, I ended up with a room on a higher floor with a better view.

The view from my room at night.

Over a thousand people came to CppCon this year, and more than half of its twenty-one corporate sponsors were trading or quant firms. The six tracks were spread across the Colorado, Red Rock, Homestead, and Willow Lake meeting rooms, and even that didn’t fill the hotel. Two other conferences were running there at the same time.

Outside the Gaylord Rockies.

Keynotes

CppCon ran five keynotes this year. These are the two I liked the most.

1. “Profiles for Simplicity and Guarantees” by Bjarne Stroustrup

   It was nice to see the creator of C++ in person. Around the venue he was basically a celebrity. On Tuesday he was also on the language designers panel with Guido van Rossum and C#’s lead designer Mads Torgersen, billed as the first time he and van Rossum had ever shared a stage. His keynote laid out where the C++ safety story is actually heading: opt-in static constraints a codebase can adopt incrementally, not a new dialect and not a Rust-style rewrite. You declare which profile you’re building to, and the compiler enforces the memory and type safety guarantees that profile promises from there. It’s a pragmatic answer to a question that’s been hanging over the language for a few years now, how to close the safety gap without asking every existing codebase to start over.

2. “The Address Is Not The Place: Object Residency in C++26” by Laurie Kirk

   Kirk’s keynote covered proposed C++26 object model changes that decouple where memory is allocated from where an object lives, aimed at relocatable objects and better interop with dynamic memory and garbage-collected runtimes. I’d heard about her before the conference, and she’s a great speaker, really enthusiastic about the material. Coming at this from the OpenJDK side, where the collector moves objects out from under running threads as a matter of routine, it’s a strange feeling to watch C++ start reasoning carefully about a problem the JVM has had opinions about for two decades. Worth tracking if you work anywhere near an allocator.

My Talk

My talk was on Tuesday, in the Software Design track: “Compile-Time Polymorphism for Runtime-Flexible Systems: Lessons from OpenJDK”. Say your program picks a strategy at runtime, from a config flag or a command-line option, and then runs it on a hot path millions of times a second. Virtual dispatch charges you on every call. Templates are fast, but they lock the choice in at compile time. The talk builds up a way to get both, one step at a time, with OpenJDK’s Access API as the running example. It’s how the JVM picks the right GC barriers at runtime. Every collector needs its own mix of barriers, and they sit on one of the hottest paths in the VM. If you’ve read the dispatch series here, a lot of it will look familiar.

I’d given this talk before, but doing it at CppCon still made me nervous. Somewhere between thirty and forty people came, mostly senior engineers, and a lot of them stayed after the slides for questions. Those went into type erasure, interfaces without vtables, and the different ways to implement RTTI (the -fno-rtti post touches on that last one), and some of it went past what I’d prepared.

Mid-talk, Homestead 3/4.

The Workshop

I spent two days in Fedor Pikus’s High-Performance Concurrency workshop before the main conference started: branchless programming, branch prediction, TLB behavior, and how much copying disappears once you actually use move semantics instead of writing code that happens to compile with them. It was a small, hands-on class of fourteen or fifteen people, so you could talk to him one-on-one.

The part that stuck with me was Pikus showing that undefined behavior can make code faster. The example was a loop indexing an array with a 32-bit counter on a 64-bit machine. If the counter is a signed int, overflow is undefined, so the compiler gets to assume it never happens and can treat the index as a plain 64-bit offset. Make it unsigned and wraparound is well-defined, so the compiler has to keep a separate 32-bit counter and widen it again on every iteration, which is a few extra instructions in the hottest part of the loop. The “safe” type is the slow one. (This Stack Overflow question has the assembly for both.) You don’t actually need the UB to get the fast version, since a size_t index is already pointer-sized and there’s nothing to widen. Still, the speedup and the danger come from the same place: the compiler assuming something you never actually promised.

Talks Worth Remembering

CppCon runs six tracks at once, so whatever you pick, you miss most of the schedule. The bar for this list was that a talk had to change something I’d actually do differently, in code or in code review. Besides the keynotes, these are the four talks I’m still thinking about.

1. “Concurrency for Modern CPUs: Lock-Free or Lock-Based?” by Fedor Pikus

   Pikus gave this one on Friday, and his answer to the title question basically came down to contention. When a lot of threads are fighting over the same data, a well-written spinlock beats a CAS loop. The trick is backoff. Losing threads wait their turn instead of retrying right away, so the cache line changes hands in batches instead of bouncing around on every failed attempt. When contention is low, it goes the other way. Even an uncontended spinlock isn’t free, because its synchronization gets in the way of the out-of-order pipeline, and he had hardware counters to show it. A single XADD or CAS doesn’t have that problem. So his MPMC queue uses both, a lock on the contended path and atomics on the uncontended one, with benchmarks on Intel, ARM servers (Graviton and Grace), and an Apple M3.

   I recognized a lot of this from my own benchmarks. In the lock-free pool post, the CAS-based free list lost to the mutex version on the two-socket Xeon in every mix except fan-out. My explanation back then was that a CAS loop has no way to stand down, while a contended mutex puts the losing thread to sleep. Pikus’s spinlock never sleeps and still beats the CAS loop, so I think sleeping was just one way of standing down. He also said “ARM vs x86” is the wrong way to compare chips, and that matched what I saw. The same CAS loop won all nine mixes on a single-node Neoverse-N1, and I’d put the difference down to the Xeon’s two sockets, not its instruction set. Lock-free isn’t going away, though. Anything that needs real progress guarantees, like deadlock freedom or signal-handler safety, still needs it. As he put it, lock-free “is not dead. It has simply relocated.”

   The concrete takeaways:

   • Heavy contention: a spinlock with backoff beats a CAS loop, because the cache line changes hands in batches.
   • Low contention: a single XADD or CAS beats a lock, even an uncontended one.
   • Both in one structure: split the contended path from the uncontended one, the way his MPMC queue does.
   • Lock-free is still the answer when you need progress guarantees, like deadlock freedom or signal-handler safety.

2. “Are You Smarter Than A Branch Predictor?” by Michelle D’Souza

   This one was set up as a game show, and the room was very lively. Two C++ snippets go up on the screen, the audience votes on which one runs faster, and then you see what the hardware actually did. The snippets came from real production code, and right answers won erasers. I didn’t answer any, so I went home without one. It made me want to go back and check every [[likely]] I’ve ever written. Branch predictors are good enough now that a branchless rewrite or a hint added on a hunch can make things slower, unless you’ve profiled it and looked at the code the compiler actually generated.

3. “Processor Design and C++ Memory Models” by Ofek Shilon

   Shilon’s abstract called std::atomic and std::memory_order “utterly opaque abstractions,” and then the talk opened them up. He went through cache coherence, store buffers, invalidation queues, and the load-store queue inside the core, and showed what a fence or a read-modify-write actually does to each of them, on x86 and on ARM and RISC-V, which can behave very differently. A lot of memory-ordering explanations eventually fall back on “the processor does weird things.” This one didn’t, and I came out with an actual picture of the hardware instead of a list of rules about which ordering is cheap.

4. “Ensuring Code Quality in the Age of AI: More Code, Less Engineering” by Peter Muldoon

   Muldoon’s point was that AI has made writing code fast, but it hasn’t made reviewing it any faster, so the bottleneck just moves to review. A big AI-generated PR that gets approved without a proper read is still a problem; it’s just a review problem now. He had some interesting takes and the data to back them up, which answered a lot of the questions people keep asking about AI. His fixes were practical: better PR descriptions, spreading reviews across the team instead of leaving them to whoever is quickest, and checklists so reviewers don’t have to rely on memory. None of it is new advice, but it matters more now that PRs keep getting bigger.

   The concrete takeaways:

   • Budget for review: AI speeds up writing code, not reviewing it.
   • Write better PR descriptions, especially for big generated changes.
   • Spread reviews across the team instead of leaving them to whoever is quickest.
   • Give reviewers checklists so they don’t have to rely on memory.

Outside the Talks

I met a lot of people over the week. There were many different restaurants to try, and many of the sponsors ran their own events on top of that: a QRT lunch, HRT drinks, and SIG’s meet-the-presenters banquet. At the banquet I got talking with Jan Wilczek, another speaker, whose type erasure talk was in the same room as mine, the slot right after. I also went to the two documentary screenings, C++: The Documentary and a preview of Boost.Documentary, and got a look at how WG21, the C++ standards committee, actually works.

The booths were a good way to see what other companies are doing with C++. Caterpillar, for example, has code that’s limited by how much power it draws, so it doesn’t overheat the machinery. I ran into the people from Undo again, who I’d first met at C++ on Sea, and there were a lot of trading firms. One conversation with an engineer from one of them stuck with me, even though it only lasted a few minutes. Their code is all C++, but they still end up worrying about the JVM, because that’s what runs at the exchanges.

What the booths sent me home with.

Conclusion

Looking back, the thread for me was that performance rules have a shelf life. Ten years ago, “go lock-free” was close to a rule for contended code. Pikus’s own abstract says that made sense on the hardware of the time, that he’d given several talks explaining how to do it, and then: “The hardware has changed.” It’s not often you watch someone update their own advice on stage. D’Souza’s talk made the same point about branches, since predictors are now good enough that branchless tricks can make code slower. And Shilon showed how differently x86 and ARM can handle the same atomic, so what’s cheap on one chip isn’t necessarily cheap on another. The old advice wasn’t wrong when it was written. The hardware moved on, and the only way to know what’s true today is to measure on the machine you’re actually running on.

CppCon wrapped with a nice view, a rainbow right over the venue on the last day.

The view from the venue, last day.

Slides and a recording for my talk should show up once CppCon finishes processing the backlog; I’ll link them from the Speaking page when they’re up. If you were in the room for the Q&A and want to keep arguing about type erasure, I’m easy to find.

Rocky Mountain Arsenal

I stuck around an extra day and went for a hike at the Rocky Mountain Arsenal, this sprawling wildlife refuge just outside Denver that used to be a wartime manufacturing site before it got turned into one of the biggest urban nature preserves in the country. We didn’t have a car, so the bison drive was off the table, but walking the trails more than made up for it: lake after lake, dead calm, mirroring the sky back at you.

One of the refuge’s lakes, the day after CppCon ended.

A pretty nice way to wind the trip down before flying home.

---

Related: Lock-Free Is Not Free: ABA, Tagged Pointers, and a Bounded Ring