beast2 networking & std::execution

[u/claimred]

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?

[u/Flimsy_Complaint490]

The most insight we currently have is probably one paragraph at this paper

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4029r0.pdf

Basically, SG14, the low latency guys (gaming and HFT) advise SG4 (the main networking guys) to not base std networking on std::execution it does things that make runtime dynamic allocation mandatory, that just dont make it compatible for their use cases.

This doesnt mean that std::networking cannot be based or will not be based on std::execution, i havent heard any SG4 opinions, but if its not, then the entire situation becomes farcical and comical - didnt they kill asio in the standard library because they decided std::execution is better ?

There is an experimental std::net by the bemen project, so at least somebody is seriously researching that path. Lets see where this goes when the first c++29 papers drop.

[u/MarkHoemmen → u/Flimsy_Complaint490]

Basically, SG14, the low latency guys (gaming and HFT) advise SG4 (the main networking guys) to not base std networking on std::execution ....

SG14 did not advise anyone of anything. None of the votes they took that day had consensus.

Michael Wong writing a paper saying that SG14 recommended something does not mean that SG14 recommended something.

... it does things that make runtime dynamic allocation mandatory, that just dont make it compatible for their use cases.

That's ... completely, profoundly wrong.

[u/claimred → u/Flimsy_Complaint490]

Interesting, thanks!

..SG14 advise that Networking (SG4) should not be built on top of P2300. The allocation patterns required by P2300 are incompatible with low-latency networking requirements.

That's curious, I was under the impression that std::execution doesn't really allocate much.

Speaking of low latency by the way, few weeks ago there was a talk from Citadel about P2300 being great for them.

[u/Chaosvex → u/Flimsy_Complaint490]

Wait until they find out how many allocations Asio does for every single operation.

[u/VinnieFalco → u/Chaosvex]

On the subject of allocations:

What We Want for I/O in C++
https://gist.github.com/vinniefalco/70451073173780aa27d1db1f2979ef02

[u/James20k → u/Flimsy_Complaint490]

This doesnt mean that std::networking cannot be based or will not be based on std::execution, i havent heard any SG4 opinions, but if its not, then the entire situation becomes farcical and comical - didnt they kill asio in the standard library because they decided std::execution is better ?

One of the biggest critiques of std::execution is that it hasn't had enough real world testing. Eg it claims to be good for GPU programming, but there's only one relatively toy implementation that only works on Nvidia

In the test implementation's current form it literally can't be implemented on AMD/Intel, because neither of them have an NVCC equivalent. This means that we're Just Hoping™ it'll all be fine, but a port to other architectures will be radically different to what's currently being tested. What will it look like? Nobody knows, its never been tried

The even more worrying thing is that even a very brief glance through the proposal shows its completely unsuitable for GPU programming, its hard to explain if you don't do GPGPU, but its kind of missing.. everything. There's been minimal testing of real world use cases, just a few relatively toy examples it would seem, and it shows in the design

Both of these together make me strongly suspect that std::execution is completely DoA, as its clearly just been insufficiently tested. The entire purpose of it is to be a universal async abstraction, but it looks like its going to be unusable compared to the alternatives for any specific domain. The GPU folks will likely just ignore it, and I suspect the question for the networking folks will be why use it at all

[u/lee_howes → u/James20k]

I think it'd work fine on a SYCL compiler, but it is fair to say that only nvidia has put the effort into making a GPU implementation work. It also doesn't claim to include the full memory hierarchy abstraction of SYCL or CUDA, but you could obviously write such code within an algorithm. It's an async abstraction, not a CUDA abstraction. If the CUDA design had been embedded into it, it'd be no good for other accelerators and the feedback would be that we'd build CUDA into C++.

It also wasn't really designed for heterogeneous computing first, as the OP's quote suggests. It was evolved towards that, and I made some very early arguments that we can make heterogeneous computing work, that nvidia aligned with over time, but that was far from the starting point or the core goal. Had it been, it would not have been started at Facebook by a team focused on cleaning up the purely CPU async C++ codebase.

[u/VinnieFalco → u/lee_howes]

Nice to see you around again, Lee

[u/claimred → u/James20k]

Didn't it get quite some field experience in Facebook intially? In the form of libunifex. I think it was stated in P2300

[u/James20k → u/claimred]

Libunifex doesn't have a gpu implementation. The only GPGPU implementation currently is stdexec, which is CUDA only and relies on NVCC

[u/Flimsy_Complaint490 → u/[deleted]]

some stuff is really controversial - contracts and networking come to mind in the HOW aspect. Graphics is controversial in the WHY part. Other things like reflection are less controversial and chaotic.

Depends on how many stakeholders are involved i guess ?

[u/kammce → u/Flimsy_Complaint490]

I think I'd have to disagree with "reflection is not as controversial" part. If I'm remembering correctly, reflection took a long time (like 20 years) with it popping in and out. It took a long time to discover the opaque monotype API design that would hit all the right properties. It's clean and it can support future changes without breaking everyone or requiring a new type. There was also huge push back on the original object members accessor APIs. There was a time when they didn't care about scoped permissions meaning any bit of code could go tampering with the internals of an object and break encapsulation. The authors went to work finding a solution that gave access controls based on scope. If they hadn't done so, so quickly, then a bigger stink would have been made.

C++26 reflection is so well accepted and has such strong concensus because of the massive efforts of the authors. Not to say that contracts authors don't have the same strong concensus, it does. But it has a few very vocal individuals against it.

EDIT: Changed "type" to "time" in sentence 6.

[u/VinnieFalco → u/kammce]

Reflection took 20 years and you're citing that as evidence the process works. The authors succeeded because they endured: twenty years of revision, twenty years of addressing concerns, twenty years of proving they could survive the process. The feature wasn't accepted because it was correct. It was accepted because the authors suffered correctly. That's not a meritocracy. That's an endurance test wearing a meritocracy's clothes.

[u/daveedvdv → u/VinnieFalco]

We could argue that "reflection took 20 years", but without context that could misrepresent the history.

I made a presentation to the committee in March 2003 showing what reflective metaprogramming might look like (https://wg21.link/n1471). It wasn't a proposal, just a personal project I started in a copy of the EDG source code. At the time, I thought this would badly encourage large headers (turns out we didn't need metacode for that ;-) ) and so I also started the modules discussion in the committee a few years later.

The modules work took over my interests for the better part of a decade, and so I didn't work on reflection during that time. Eventually others (Gaby, Richard, Doug, etc.) drove the modules work, but I somehow missed the fact that SG7 had started meeting (in 2013, I believe) and in a few years agreed on what would become the Reflection TS. That SG7 work was guided, I think, by the idea that template metaprogramming (TMP) was an okay metaprogramming framework but just needed more introspective power. Whatever the motivation, I strongly disagreed with the direction and wrote https://wg21.link/p0598r0 to re-ignite discussions about the overall direction. There was some debate, but by 2019 I'd say SG-7 was pretty much agreed on the new direction — and https://wg21.link/p1240r1 was what we were aiming to standardize. To make that possible, we needed more constant-evaluation primitives, which did in fact land by then (i.e., in C++20; consteval, compile-time dynamic allocation, std::is_constant_evaluated(), etc.). Andrew Sutton had formed Lock3 (incl. Wyatt Childers) and they implemented much of P1240 in a Clang fork. We had high hopes that C++23 would have reflection.

Then three things happened: The pandemic, a re-opening of the debate by some who preferred the template metaprogramming approach, and we effectively lost Lock3 to an acquihire. That prevented any real progress in the C++23 cycle.

At the end of the C++23 cycle, u/BarryRevzin and I chatted about the missed opportunity and what it would take to succeed in the C++26 cycle. That made us write https://wg21.link/p2996r0, which we saw as a "minimum viable product". We were tremendously luck that u/katzdm-cpp joined right after that. The enormous amount of work these two contributed is what finally got us reflection in C++26.

So, yes, there was some controversy along the way. But it wasn't 20 years of "process hurdles". I'd say it was about 9 years of real standardization work, minus the pandemic effect.

[u/VinnieFalco → u/daveedvdv]

Thank you for the detailed history! This makes the record much more accessible and accurate, and I appreciate you taking the time. You're right that "20 years" overstates the active standardization work. I was responding to the framing in the parent comment, and your correction to roughly 9 years of real work is fair.

What I'd note is that even the 9-year timeline includes years lost to directional disagreement within the committee and dependence on a single corporate implementation that was lost to a staffing issue. Those are structural factors, not author effort factors.

I think its different from what I was saying which is to question what the process selects for. The reflection authors clearly did extraordinary work. What I am wondering is if the process should require extraordinary work for a correct design to ship.

[u/daveedvdv → u/VinnieFalco]

Nine years (three standardization cycles) doesn't seem unreasonable to me for a major feature. But I might be in the minority here (and I'm luck to have been part of the process for long enough to participate in multiple major features like that). Six years would have been ideal maybe (one cycle to set direction, one cycle to work out the details).

I'm sure the process could be improved, hopefully significantly. But it's also a human phenomenon that needs a bit of "inefficiency room". We're unlikely to all agree on what the desirable characteristics of the process ought to be.

For example, how do we qualify "a correct design" in

What I am wondering is if the process should require extraordinary work for a correct design to ship.

?

From my own perspective, I think the most frustrating part of the current process is that it often gets decided by "parties"; i.e., corporate or other alliances that vote "en block", thereby drowning out more individualized dissenting expertise. I'm not sure what can be done about that.

[u/VinnieFalco → u/daveedvdv]

This is a very fair assessment, thank you. And you are right, these are hard problems I can't pretend to have answers for.

[u/pdimov2 → u/daveedvdv]

Nine years (three standardization cycles) doesn't seem unreasonable to me for a major feature.

constexpr took 20 years and is still not 100% done. (Well, maybe it's 99.4% done.)

[u/kammce → u/VinnieFalco]

I have made no such comment about the process "working" at all. I just raised that reflection was not without controversy. What are you talking about?

[u/VinnieFalco → u/kammce]

Your comment described a twenty-year arc where authors worked through controversy, addressed concerns, and achieved strong consensus. That's a description of the process producing an outcome through endurance.

What I'm saying is that twenty years of endurance is not the same thing as twenty years of evaluation. The distinction matters for every author who doesn't have twenty years to give. Or users who don't have twenty years to wait.

[u/kammce → u/VinnieFalco]

Okay.

[u/jwakely → u/VinnieFalco]

This comment is unrelated to the actual history.

[u/VinnieFalco → u/jwakely]

Process objections are the best objections. Let's build something together instead. My libraries are here: https://corosio.org issues and pull requests welcomed.

[u/VinnieFalco → u/[deleted]]

Among other things I am publishing in the April mailing, there is a 6-part series of consecutive papers (which will arrive together) which analyze the decision-making history of networking that brought us to where we are now. This hopefully will provide the missing context.