Trying Out C++26 Executors

Summary

Trying out C++26 executors 21 Nov 2025 on C++, Game development, Graphics programmingI wanted my program to boot up faster so I tried to multithread it with both executors and the more classic TBB.Back in 2020 I did a remote talk at CppCon about my work on making Stellaris boot up much faster. I later brought similar improvements to Hearts of Iron IV and Europa Universalis IV (although I’m afraid the latter was never pushed to the live branch, you have to opt-in to a beta version). They key to those improvement was, of course, concurrency: put stuff to load in the background if it’s not needed upfront, and use multiple threads to do the work when possible.One of my goals this year has been to get into graphics programming, using my spare time between clients to play with OpenGL, raylib, SDL3_GPU and more recently, Vulkan. My latest project is to build a Vulkan renderer step by step, and as it grew so did the startup times. It’s still only a matter of seconds (even in Debug) yet I thought it would be interesting to take advantage of Vulkan’s strong push towards multithreaded graphics to get some prototype going, and use the lessons learned to eventually make a proper efficient asset loader.And so I got thinking, while I could definitely do it with some combination of C+11 future/promise/async and C++17 std::execution::par_unseq loops, or use TBB (which was my go-to on production games), I figured I should give the upcoming C++26 executors a shot.The use caseMy project currently has only a few assets to load, but they each take some measure of CPU time:The mesh drawing pipeline uses 2 shaders (vertex + fragment) that need to be compiled from GLSL to SPIRVThe test mesh itself uses PNG for textures, which need to be decompressed to RGBA before they can uploaded to VRAMOf course, a production game would usually have a baking process to avoid both of these caveats, making sure to ship pre-compiled SPIRV shader blobs and assets optimized with textures that can be directly ...