There’s a lot to write about std::simd in C++—too much for a single post.
I’d like to show how std::simd helps solve actual problems.
Like every tool, it’s not a one-size-fits-all solution.
Pick the tool that suits the problem.
And if you already have a good tool for your problem or the auto-vectorizer understands your code just fine 🤷 great, no one is asking you to switch.
However, maybe I’ll be able to broaden your perspective on its capabilities and the specific challenges it addresses.
Introduction to std::simd in C++26 (Part 1)
std::simd in C++26 (Part 1)Your AI Coding Assistant Is Not a “Junior Developer”
Listen into a conference talk or onboarding session on AI coding assistants, and you will hear the same metaphor. The AI is the “junior developer” or “co-worker” on the team. You mentor it. You review its work. You trust it with routine tasks, not the hard problems. The framing feels natural, modest, even generous. It is also, we will argue, wrong in a specific and consequential way. Calling an AI a junior imports trust and patience that the system cannot earn. It trains teams in the wrong review habits. It risks skipping over the exact experiences that turn juniors into seniors in the first place.
My vision for an interdisciplinary RSE institute: how to actually help scientists
Today I attended a talk by Dr. Florian Mannseicher on FutuRSI—an “initiative […] to conceptualise a German research software institution”. The discussion around critical challenges and concrete needs facing the research software community resonated with me—particularly because I discussed many of these same issues—still unresolved today—in 2020 in “Software Engineering as Scientific Infrastructure”. I believe FutuRSI should be the place to solve what I wrote about back then. I’ll elaborate in this post. Since 2020 our ability to talk about these issues has improved. “Research Software Engineering” (RSE) has become a widely used term. There are conferences on RSE. But the main problem has not been addressed—in my opinion.
Virtual Trip Report: WG21 Kona 2025
After the CD (committee draft) is out, WG21 is in bug fixing mode. Consider NB comments as the tickets that force us to consider a resolution and provide an answer. Such issues can either be design issues or wording issues (where wording does not match stated design intent). Besides NB comments, many library issues had been filed and prioritized independently, which led to several categorized as must/should fix before the standard is finalized.
The story of regularity and std::simd
In this post I will talk about regularity and why
std::regular<std::simd<int>> needs to be false in order to preserve
regularity at the level where it matters: equational reasoning. The issue of
regularity came up repeatedly when discussing the design of std::simd for
C++26. (It also came up in 2017 for std::experimental::simd.) My goal for
this post is the exploration of options and their consequences. There’s a lot
more to be said, but this post is already too long. In any case, when talking
about regularity, we need start with “Elements of Programming”, the book that
introduced the concept:
A type is regular if and only if its basis includes equality, assignment, destructor, default constructor, copy constructor, total ordering, and underlying type. […]
Algorithms are abstract when they can be used with different models satisfying the same requirements, such as associativity. Code optimization depends on equational reasoning; unless types are known to be regular, few optimizations can be performed.
Alexander Stepanov, Paul McJones — Elements of Programming (EoP)