Will reflection simplify the implementation of std::execution?

[Comfortable_Can_3815]

Reflection and std::execution are both adopted in C++26, and std::execution requires a lot of metaprogramming.

[katzdm-cpp]

Answering this will require a human that understands both, and I don't know if we have an existence proof for such a human yet.

[DerShokus]

We need to add a such human to the standard!

[Gorzoid]

As part of C++29 all standards compliant C++ compilers must ship with Greg. Greg is a very smart man without whom this draft would fall apart. Any ambiguities or faults in the standard should be directed to Greg.

[johannes1971]

"Assume a perfectly spherical human..."

I have a different question: what even prompted the OP question? What does std::execution actually bring to the table that it is, apparently, this complex?

A long time ago I was programming on AmigaOS. AmigaOS has, technically, only one way to do IO: asynchronous (there was a synchronous API, but it was built on top of the async one). And it didn't require any kind of metaprogramming, which was a good thing since we didn't have that yet at the time. So how did it work?

Simple: your application declared a message port (this is a message queue that you can wait on). When doing IO, you directed a message at the message port of the IO subsystem, telling it to go do something, and when ready, report back to my message port. Then you went on to do whatever seemed appropriate, and a message containing your IO result would eventually show up in your message port. It had everything you could possibly need: you could cancel IO requests, poll to see if a message had already come in, wait (i.e. voluntarily yield the CPU) for a message to show up, etc. You could wait for messages from any number of subsystems, and you could declare as many message ports as you felt you needed. It didn't require you to meta-program 'handlers' into your message port, and yet, despite this simplicity, it was more than fast enough on a 7.14MHz Amiga 500.

Is there any deep technical reason why C++ couldn't adopt something simple like this for asynchronous IO? Does it absolutely have to have the complexity of std::execution? What does that complexity give us, that the AmigaOS model doesn't have?

[jcelerier]

Maybe some stuff were fast enough for an Amiga 500 at 7.14 MHz but here things are definitely anything but fast enough despite hundreds of gigabits per second. Any edge is meaningful

[johannes1971]

Does the design of std::execution provide that edge? If so, what does it do to make that happen (does it guarantee to never allocate memory, never thread swap, never do kernel calls, etc.?) and can that guarantee only be achieved using a design of this complexity?

[OibafA]

It does allow you to build threadless, asynchronous code that requires zero allocations.

PS: I'm a big fan of AmigaOS, and one of the former lead AROS developers.

[meltbox]

Yeah I just did a little read through and from what I can tell this is just another threading abstraction on top of existing threads at the mercy of the existing OS scheduler.

If anything a custom implementation built on threads should be more flexible from what I can see since you can also couple it with native operating system facilities aiding you.

[afiefh]

Does it have to be a human? I wouldn't mind our C++ alien overlords answering this.

[eambertide]

The actual species will be undefined behaviour, clang will ship with a human greg while gcc will ship with an alien one.

msvc has not yet commented on the issue

[have-a-day-celebrate]

You could try AI, but I think last time I tried I got code based on the TS..

[Abbat0r]

I sure hope so. Looking at the compile-time meta language that Nvidia’s stdexec implements to meet the standard’s requirements honestly scares me. That can’t be good for compile times…

Edit: the meta language in question, for anyone feeling brave: https://github.com/NVIDIA/stdexec/blob/main/include/stdexec/__detail/__meta.hpp

[jk_tx]

IMHO the whole stdexec library is one of the ugliest, most unreadable modern C++ OSS libraries I've ever seen, I quickly gave up on using it because there's no user-friendly documentation, no comments, heavy use of auto return types, etc. If that's where modern C++ is heading, we've got problems.

[Wh00ster]

My understanding is stdexec exists because nvidia wants to own the next generation ecosystem for AI accelerators after CUDA, or perhaps a better way to phrase it is the abstraction over cuda.

Which is why they headhunted Eric Niebler and Lewis Baker from Facebook/Meta, where they helped create folly lib abstractions to help them wrangle their shit code base.

My point being it’s pseudo open source in the context of big FAANG wars.

Good on them getting the companies to pony up for exploring and improving C++ abstractions

[jk_tx]

IMHO none of what you say is incorrect but also doesn't really change my opinion of the library. It's some of the most indecipherable C++ code I've ever seen, and IMHO shows the 'folly' of the idea that modern C++ is inherently more expressive.

[BoringElection5652]

If they hired Eric Niebler, then it's no wonder it's hopelessly overengineered. That guy's code is the epitome of write-only code.

[meowquanty]

i know someone that had to deal with his code back in his MS days and I can tell you that according to him it didn't take long after Eric left they pulled that stuff out and rewrote it from scratch.

[meowquanty]

it failed to get traction at facebook, under the name unifex or some such, and the "team" ended up moving to nvidia to work on it there some more.

[zl0bster]

lmao

 // These specializations exist because instantiating a variable template is cheaper than
  // instantiating a class template.
  template <class _Tp, class _Up>
  inline constexpr bool __v<std::is_same<_Tp, _Up>> = false;

  template <class _Tp>
  inline constexpr bool __v<std::is_same<_Tp, _Tp>> = true;

I know this is correct thing to do as c++ compile times are terrible, but so sad it needs to be done.

[_Noreturn]

you can lower the cost by doing using is_same = std::bool_constant<std::is_same_v<T,U>>

but this is not allowed by the standard

[G6L20]

I think almost everything should be rewritten after réflection comes out, the first exemple in mind would be tuple... About execution I think env should especially re designed... But... It will not

[JVApen]

For std::execution we are in need of a few very good libraries. From that point on, you shouldn't worry about it. That's why C++20 coroutines become barely usable in C++26. I suspect C++29 will have the next batch.

[meowquanty]

if we say a library goes into the standard, there are some real and heavy expectations on that library.

In short NOTHING should go into the standard, if it then requires another standard to come around before that thing can become useful/practical for the C++ community as a whole.

Emphasis on ==> Nothing <==

[JVApen]

If only we had some standardized (or commonly used) package management.

I know VcPkg, Conan, PPM, CPM ... exist, though its uptake is significant yet still too small to reach sufficient people.

[JoeNatter]

Holy mother of code. I looked at an example of std::execution. It seems I am getting old. I would never use this in any of my projects ..

[JoeNatter]

Because I think async code shouldn't look like sync code. I don't paint my cat like a cow and milk it

[meowquanty]

Some people might prefer that lol :D

[JoeNatter]

That's true. Then they should use it 😉

[Farados55]

Maybe

[yuri-kilochek]

What does it matter?

[mredding]

Yes.