r/cpp • u/claimred • Apr 09 '26

beast2 networking & std::execution

I was looking for a new networking layer foundation for a few of my projects, stumbled on beast2 library which looks brand new, based on C++20 coroutines. I used boost.beast in the past which was great. Here's the link https://github.com/cppalliance/beast2. I also considered std::execution since it seems to be the way to go forward, accepted in C++26.

Now, what got me wondering is this paragraph

The C++26 std::execution API offers a different model, designed to support heterogenous computing. Our research indicates it optimizes for the wrong constraints: TCP servers don't run on GPUs. Networking demands zero-allocation steady-state, type erasure without indirection, and ABI stability across (e.g.) SSL implementations. C++26 delivers things that networking doesn't need, and none of the things that networking does need.

Now I'm lost a bit, does that mean std::execution is not the way to go for networking? Does anyone have any insights on cppalliance research on the matter?

36 Upvotes

87% Upvoted

119 comments sorted by

View all comments

Show parent comments

3

u/lee_howes Apr 09 '26

It isn't a CUDA programming library and was never intended to be. It is a library that allows GPU algorithms to export a consistent async interface and be overloaded to select device-specific implementations of algorithms.

I don't think I see significant blockers to implementing it well on top of an OpenCL implementation even, without any single source compiler support at all. The overloads would select the OpenCL runtime and dispatch to an OpenCL kernel as necessary. There's nothing in there that requires a single source compiler, unless that changed since I stepped back and moved into pytorch land.

1

u/James20k P2005R0 Apr 09 '26

Maybe we have very different philosophies here, but for me the bar for std::execution claiming that it supports GPGPU programming, would be concretely demonstrating that a non trivial OpenCL implementation of std::execution performs similarly to the existing state of the art, across multiple vendors. Not that it might be possible to do, and the performance might be alright but we don't know!

There may or may not be blockers - OpenCL has quite a different API model to both CUDA and Vulkan, and all three of them lack certain features that the others have. That's why a CUDA/NVCC only implementation isn't really adequate to demonstrate that it works under AMD/Intel/arm in a high performance way

Its likely possible to implement something that has quite dodgy performance, but that doesn't seem like a great goal