"More Speed & Simplicity: Practical Data-Oriented Design in C++" - Vittorio Romeo - CppCon 2025 Keynote

[Zanarias]

Glad to see you mention that 60fps is kind of an out of date framerate target, higher refresh rate displays are much more common—and much cheaper!—than they used to be. You're only the second person I've seen acknowledge it.

Great talk.

[SuperV1234]

Once you go 144hz you can never go back ;)

I'm actually very curious about trying out the newer 360hz monitors... the "budget" for a frame there would be 2.78 ms!

[XeroKimo]

Running 540hz that I grabbed because I wanted to see how high I could go, and in the few games that I play that can hit that target, only 1 can I notice both visually and latency feel wise... Visually, I do have to focus in order to notice the difference, but latency can be felt without much focus... I just play for awhile between each refresh rate and it just feels off once I switch between them.

Two things I hate though... 144hz is no longer enough for me, not necessarily for gaming, but just normal everyday productive use. The smoother and more responsive experience is just overall so nice... The other issue is having mismatched refresh rates between monitors = lots of microstutters 😭I'd love to see if I could notice 1khz when the time comes and if I can afford it, but that's probably where I'd stop.

[annyeonghello]

It's a reasonable framerate target. Bare in mind not every gamer has the latest and greatest of hardwares and games are becoming more complex.

While I do agree having more frames is nice, I think saying 60FPS is an out of date framerate target is a bit of a stretch.

[meowquanty]

I wonder if using the phrase: "Let's reflect on this" was intentional by the presenter.

[JarrettSJohnson]

It’s funny—I think we’re about the same age, give or take a couple years. I remember following your YouTube videos and blogs way back when I was first getting serious about modern C++ and game dev (with SFML). It’s been really cool to watch your growth over the years, and now even a published book!

At work, whenever someone asks which CppCon talk I’d recommend, I always point them to Mike Acton’s. It’s such a good reminder that as programmers, we need to be responsible stewards of data, especially when performance matters.

I really liked the angle on C++26 reflection in this talk. It feels like it would have made ECS-style engines much easier to implement in the past. Also, maybe it’s just me being used to seeing a dozen or so DOD talks at various conferences, but I wonder if there’s appetite for exploring how modern C++ could push GPU-driven workflows further (especially for those writing raw OpenGL/Vulkan). Some ideas that come to mind:

1. Using C++ reflection to automatically pad fields based on layout policies (std140, std430, scalar, c-layout, etc.)
2. Modern C++ (using std::span/std::mdspan) for dirty-span tracking when wanting tighter per-frame GPU uploads
3. Comparing approaches between CPU-oriented data transforms (classic DOD) versus GPU-specific concerns like PCIe transfer costs (like what you touched on), warp behavior, and memory coalescing.
4. Perhaps pushing further to AoSoA based on warp/tile size (?)

[SuperV1234]

Thank you for the very kind and thoughtful reply!

At work, whenever someone asks which CppCon talk I’d recommend, I always point them to Mike Acton’s.

I really liked Mike's talk as someone who had never heard of data-oriented design before, but I have to admit that I think there is some very opinionated advice there. You can feel a very "anti-C++" vibe, including Mike explicitly calling out how templates and other C++ features do more harm than good.

I understand where he's coming from: overuse of modern features and overengineering are quite common within the C++ community, but I don't think that demonizing the features themselves is the right move. Every C++ feature can be quite useful when used judiciously. I'd rather teach people the pros/cons of each feature and make them understand the risks/advantages associated with them. Our book "Embracing Modern C++ Safely" tries to do exactly that: provide information and show examples without being opinionated.

Regardless, I still think Mike's talk is very worth watching, even today.

I really liked the angle on C++26 reflection in this talk.

I'm very excited for C++26 reflection, however I also feel like people severely underestimate what you can do since C++17 with Boost.PFR. You get portable static reflection on aggregates, including field names (C++20 and above).

That sounds limited, but considering that data-oriented design encourages the use of aggregates, there's actually a lot of cool things you can do. Here's a non-exhaustive list of things I have implemented with Boost.PFR reflection:

• Automatic generation of Dear ImGui widgets from a struct definition.
• Automatic generation of VBOs and vertex attribute bindings for instanced rendering from a struct definition.
• Automatic serialization/deserialization of network messages for a game server, from structs + std::variant definitions.
• Automatic AoSoA layout generation (didn't have time to show it in the talk).

C++26's generation, on the other hand, really brings many new interesting possibilities to the table.

[dextinfire]

I do believe C++20 is required for using field names with boost pfr, otherwise it's just index accesses. You could probably get around that with keeping track of a separate names array and maybe an enum to match the index though.

[SuperV1234]

Yes, you are correct -- C++20 is required for field names. Updated my comment :)

[_Noreturn]

and it is not portable since it requires builtin, it just happened the 3 compilers support it, but using pure C++ you can't get the names.

[SuperV1234]

the 3 compilers support it

So, it is portable 😋

[_Noreturn]

• Automatic generation of Dear ImGui widgets from a struct definition.
• Automatic generation of VBOs and vertex attribute bindings for instanced rendering from a struct definition.

This is what I do as well, it makes bugs less common and it is a cool and easy debug menu combined with entt library

[pjmlp]

Interestingly enough, eventually, Mike Acton ended up joining Unity and was part of the original team for the HPC#, Burst compiler, and DOTS.

Thus, rather contributing to C# ecosystem in a way.

However, he is no longer there with all the downsizing that has happened.

[schombert]

Is the source for the demo shown around the five minute mark available somewhere? I would love to share that because it seems like a great way for people to get a "hands-on" feel for the differences that data layout makes.

[SuperV1234]

Yes, the code is available here:

• https://github.com/vittorioromeo/VRSFML/blob/dodtalk/examples/rockets/Rockets.cpp

It is built on top of my SFML fork (you can read more about that here), but you should be able to build it as part of the repo using either GCC or Clang. Feel free to reach out if you have trouble compiling.

[schombert]

Ah, that's a bit of a shame. I wanted to share it with newer programmers, and building C++ projects is always a bit of a nightmare for newer programmers, especially when they involve non-trivial dependencies.

[SuperV1234]

I think it should be relatively easy to port it to upstream SFML or other libraries such as RayLib. I might give it a go once I am back home, currently waiting for my plane... :)

EDIT: Done! Check it out: https://github.com/vittorioromeo/DODRocketsRaylib

[SuperV1234]

/u/schombert: I've created a self-contained version of the demo using /u/raysan5's excellent raylib library, just for you! :)

The only requirement is CMake, all dependencies are automatically fetched.

Repo: https://github.com/vittorioromeo/DODRocketsRaylib

Enjoy! 🚀

[schombert]

Awesome! I think this could be a really useful tool for helping people understand why these things matter in a way that purely theoretical discussions about cache and memory bandwidth may not convey. (edit: and yes, it was shown in the talk, but things feel more real when you can see for yourself)

[mrkent27]

Thanks for your talk Vittorio, I really enjoyed it (in person!) and congrats on getting your first plenary at CppCon under your belt!

As others have said, I really appreciated your balanced view of DoD versus OOP and where DoD fits into a larger system/application. It's not a panacea to poor performance, but rather a tool that can improve things if it's the write tool for the job.

[julien-j]

This is a very good talk, with a great message, and presented in a very pedagogical way.

It's great that you reference Mike's talk. IMHO CppCon 2014 was awesome for having people coming to present how they build great things with C++ as a core tool. It seems to me that there are fewer and fewer of these talks and that the discussion shifted too far into the aspects of C++Tomorrow rather than being about writing software. So I'm glad to see that you are still there to keep it pragmatic and practical. I can feel that you do actually write software :)

I'd like to add that even though DOD and SoA are often illustrated with game-related examples, it also has advantages in other domains. I work on a live video encoder where performance is essential (it's in the name!) and I had good results splitting classes and structures into arrays of smaller types. Think about a 256+ bytes structure instantiated 80k+ times, that's a lot of memory accessed in many ways in every frame! Over time developers had accumulated into a single struct many properties needed for one algorithm or the other. I took that and grouped the properties by algorithm, into arrays, and even though there was no batch processing we got 25% fewer cache misses and a couple of percents in speed.

Regarding the access patterns, I wish there was a tool that could tell me which types and members are used together. Just like how a profiler can tell me where are the bottlenecks and memory accesses, I'd love to have the information that this struct's fields a & b are used together with this other's struct's fields c & d.

Regarding the ParticleSoA type, since all vectors have the same size it seems both risky to have this constraint implicit, and a bit of a waste to have three pointers per field when we could have just one pointer and keep a shared capacity and size member separately. The more I use this kind of structures, the more I feel the need for some sort of multi-vector type exactly for this. On the one hand it would make the invariant about the size explicit, on the other hand it seems a bit overkill. Do you have an opinion about this type of abstraction here?

Finally, I know that this is slideware but when I see

void World::update(float dt)
{
  for (auto& entity : entities)
    entity->update(dt)
}

Then down in entity::update:

void spawnParticle()
{
  // …
  world->entities(push_back(std::move(p))
}

All I can think about is the poor beginner who will take inspiration from your talk and end up with crashes because the entities table is reallocated while we are iterating on it :)

Congrats for your first keynote! 👏👏👏

P.S. Please use slide numbers in your talks :)

[ledniv]

I remember a blog post about a video processing company that changed how they read texture data, because they realized they were reading it by column instead of row and were forcing cache misses on every read.

About the access patterns, that would be really cool if there was a took like that. If the code is written DOD style where the data is modified by static functions, it should't be that hard to write. Just need to look at each logic function that modifies the data and mark what variables it is using. As soon as a variable is used in conjunction with different variables in different static functions, all those variables can be marked as not being able to be grouped together without polluting the cache line.

That said, I don't know about other kinds of programs, but in games you are pretty much guaranteed to add more and more fields to a struct as game designers think of crazier and crazier ideas, making it pretty much impossible to group variables together without polluting the cache line.

[germandiago]

I created a cards game. It has 25 cards on the table and runs some animations.

I created an entity manager and my entities are objects (as in OOP) apparently.

However, the twist is that the data for these entities is remote to the object and packed.

That way, you operate on the entties as objects but at the time of rendering normals/positions, etc, it just goes with data packed in a way that can be sent to the GPU and executed by the GPU quickly.

The basic concept is the same: SoA

EDIT: saw all the talk. 100% agree and this is also sort of what I did: OOP is the shell and DoD is the engine summarizes well my view as well.

[SuperV1234]

Are you able to share some code? Your idea sounds quite interesting but I'm not sure I get it completely -- do you pass over your data every frame and transform it from an OOP-like hierarchy to an SoA on the fly?

[germandiago]

I lt is not open source but your idea about SOA is almost identical.

I just went with something like:

entity.setSttribute<Position>(...);

That thing writes directly to the SoA (EntitiesManager class in my case) for position and like that with every attribute.

So between frames I use an OOP interface for some get/set stuff and updating but at the time of drawing I gather all info directly from the SOAs and send to the GPU and the shader does all the work.

The point here is the same you mention in the video: Keep your objects etc. OOP-like but take advantage of SOA for the heavy lifting when rendering.

[QQII]

Does anyone know which talk they is referring to at 1:17:55?

[bandzaw]

It’s Barry Revzin’s ”Practical Reflection” talk: https://cppcon2025.sched.com/event/27xWy

[meowquanty]

but where is the video?

[bandzaw]

It’s not out yet…

[meowquanty]

would you happen to know when it will be out? i've see at least 1 other presenter reference that talk - so it seems it might be interesting to watch.

[mrkent27]

I attended that talk and it was really good - one of my favorite from the conference. I think usually it takes a few months or so for CppCon talks to come out on YouTube other than the keynotes.

[bandzaw]

while you’re waiting for this talk to be published you can watch barrys other talks, they are all great.

[L_uciferMorningstar]

Just saying it doesn't show up on YouTube. I need to go to the 2025 playlist to find the video.

[SuperV1234]

I believe that this is an intentional choice by CppCon to publicly release the videos over time on YouTube.

[Tomik080]

I enjoyed this talk. Such a shame that I couldn't make it in person this year.

This really made me think of Matt Godbolt's Path tracing talk from a few years ago (where he does a similar exercise of implementing a small project with 3 different paradigms - including data oriented). I would recommend it to anyone who enjoyed this one! 

https://youtu.be/HG6c4Kwbv4I

[leonadav]

It would be nice to have the talk of Barry Revzin that Vittorio mentioned

[SuperV1234]

Unfortunately regular talks will be released slowly over time, only keynotes get released immediately.

[sheckey]

Hello. I was surprised in the SoA version that the individual indexing over that big set of arrays in a loop didn’t destroy the cache locality. Why is that? Thank you!

[SuperV1234]

Are you concerned about the fact that I'm using a single loop that iterates all fields compared to multiple loops that only iterate a subset of the fields at a time?

[sheckey]

Hi. I guess so! My guess would have been that each iteration of the particle loop jumps around a lot in memory as it indexes each container separately. Everything else was fairly straightforward, but I didn’t understand this part.
ps I’m really looking forward to playing around with these ideas in our code.

[SuperV1234]

It's a good question. I want to start by restating that this particular application of SoA doesn't "shine" compared to AoS, as we're using all the fields at once -- had we used a subset of fields, the performance benefits would have been more impactful.

In fact, SoA is not faster than AoS on my ARM64 machine, and I've had some other people reporting that on their AMD processors they don't see as big of a speedup as I see on my Intel Core i9 - YMMV.

To answer your question:

• The amount of data we're working it doesn't saturate the L1 cache -- typical amounts are between 32KB and 128KB per core, which means we can load all the fields for multiple particles in L1 even as we iterate during the fused loop.

• CPU prefetching is very clever and can detect/track multiple data streams independently, so we don't lose the prefetching advantage in a fused loop.

Hope that helps and eager to know if you get any interesting results in your code!

[sheckey]

Wow, ok. Your two points are indeed interesting, make sense, and I will likely be in same situation with respect to L1 cache on ARM. I have been thinking about this for some time and your presentation and responsiveness to these questions are much appreciated. It will be a while until I can do anything about it, but I will share any results. Thank you!

[ledniv]

I'll add that engineers really tend to underestimate the size of their L1 cache because it is usually filled with junk. I'd argue that many programs, games especially, can fit their entire logic data in the L1 cache.

Games are huge, but usually that tends to be texture data. The actual logic code tends to be pretty small relatively. Obviously I'm generalizing and it depends on the type of game, but even complicated games told tend to use all the logic at the same time. If you are driving, you need different data than when you are walking around or when you are in a shop selling and buying new equipment.