auto curried_async_foo(params_t params) {
return [params](invokable<result_t> cont) {
async_foo(params, cont);
};}
...
auto op = curried_async_foo(params);
op(receiver);
- finally modify the curried variant to add another required evaluation round:
auto foo_sender(param_t params) {
return [params](invokable<result_t> cont) {
return [params, cont]{
async_foo(params, cont);
};};}
...
auto sender = foo_sender(params);
auto operation = sender(receiver);
operation();
The actual library uses structures with named methods instead of callables (so you would do operation.start() for example), plus a separate continuation for the error path (by having the receiver concept implement two named functions), and cancellation support. Also the final operation is required to be address stable until it is completed.
The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).
The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.
> can avoid or defer a lot of the expected memory allocations of async operations
Is this true in realistic use cases or only in minimal demos? From what I've seen, as soon as your code is complex enough that you need two compilation units, you need some higher level async abstraction, like coroutines.
And as soon as you have coroutines, you need to type-erase both the senders and the scheduler, so you have at least couple of allocations per continuation.
I can't comment on this particular implementation but few years back I played around with a similar idea, so not quite 1-to-1 mapping, but my conclusion derived from the experiments was the same - it is allocation-heavy. Code was built around similar principles, with type-erasure on top of future-promises (no coroutines back then in C++), and work-stealing queues. Code was quite lean, although not as feature-packed as folly, and there was nothing obvious to optimize apart from lock-contention, and dynamic allocations. I did couple of optimizations on both of those ends back then and it seemed to confirm the hypothesis of heavy allocations.
I have only played very little with it and I don't have anything in production yet, so I can't say.
I did manage to co_await senders without additional allocations though (but the code I wrote is write-only so I need to re-understand what I did 6 months ago again).
I recall that I was able to allocate the operation_state as a coroutine-local, and the scheduler is node based, so the operation_state can just be appended to the scheduler queue.
You still do need to allocate the coroutine itself, and I haven't played with coroutine allocators yet.
The article is one-level up where it is both using higher level combinators and the pipe syntax for chaining sender and receivers. I do find that hard to reason as well.
My reduction to continuations is, I think, derived form Eric Niebler original presentation where he introduced a prototype of the idea behind sender/receivers.
With all the changes in C++, it always makes me wonder how developers these days reason about what the code is actually going to compile to and perform like. I feel like I have a good enough understanding of C and of older C++, but there's a constant influx of new syntax and new concepts in C++, and for a language that is supposed to be for systems programming, much of that seems so far away from "the machine".
> it always makes me wonder how developers these days reason about what the code is actually going to compile to and perform like
What will it compile to? Check out Compiler explorer [0].
What will it perform like? Use benchmarks [1] [2]. Remember that benchmarks heavily depend on what system you're using. Benchmarks for generically-compiled software on modern hardware will look very different than benchmarks for the same software but hyper-optimized to run on 10-year-old hardware.
So: if it's not tested, it's not Engineered.
For tests, I strongly prefer GTest [3], for a fairly consistent API across benchmarking, testing, and mocking.
> there's a constant influx of new syntax and new concepts in C++
Yes, but you don't have to use all of it. You can still use older C++ if you really want to. I wouldn't recommend it though. I think the "sweet spot" right now is around C++17. It's got quite improved safety compared to "old" C++ (say... pre C++11) and is fairly easily understandable if you're coming from "old" C++.
"Hmm, we need a new keyword to express this complicated idea about how geese move, in other languages they seem to use the keyword fly"
A1: Just re-use this existing four letter keyword 'swim'. Yeah, technically a goose can also swim but that's different, and the ideas aren't similar, and the implementation is entirely different, but this way we didn't need a new keyword so it's less work for a compiler right?
A2: Simple, new keyword complicated_goose_motion - why are people not happy with that?
At some point a noob will ask "Hey why can't we just name it `fly` like in Other Language?" and they will be ridiculed because of course several C++ companies have used the word fly as an identifier in software, and so reserving that word would incur a slight annoyance for them, whereas just forcing either A1 or A2 avoids a little work for those companies and is thus better...
I love C++ for the power it gives me, but boy do I hate reading C++ code. I know most of these things are for historical reasons and/or done because of parser compatibilities etc. but it's still a pain.
A lot of it is about making metaprogramming a lot easier to write and to read.
No more enable_if kludges since if constexpr (and concepts for specific stuff); and using concepts allows to better communicate intent (e.g.: template<typename I> can become template<std::integral I> if you want the template to be used only with integer types, and so on)
Thankfully, you can still write C++ just fine without the "modern" stuff and have not only readable code, but also sane compile times. The notion, explicitly mentioned in the article, that all this insane verbosity also adds 5 seconds to your build for a single executor invocation is just crazy to me (it is far longer than my entire build for most projects).
It's not crazy, it's just what happens if you write mostly C with some conveniences where they actually make sense instead of "modern C++". I generally write very performance sensitive code, so it's naturally fairly low on abstraction, but usually most of my projects take between one and two seconds to build (that's a complete rebuild with a unity build, I don't do incremental builds). Those that involve CUDA take a bit longer because nvcc is very slow, but I generally build kernels separately (and in parallel) with the rest of the code and just link them together at the end.
Sure, C++ is heavy for compilation, there's simply more by the compiler to do, but code repository building under 5 seconds is at the very low end of tail so making the point about someone bearing with the 5 seconds longer build time is sort of moot.
I wrote a lot of plain C and a lot of C++ (cumulatively probably close to MLoC) and I can't remember any C code that would compile in such a short time unless it was a library code or some trivial example.
The authors and NVIDIA do not guarantee that this code is fit for any purpose whatsoever.
And say that it worries them. This is actually a warranty disclaimer (the warranty of fitness for a particular purpose) and has to be written like this to be effective. So I would not read anything into it
It's funny because I remember the first time I tried Linux (Debian) nearly 25 years ago, that "NO WARRANTY, EVEN FITNESS FOR A PARTICULAR PURPOSE" warning in all caps really did leave a bad taste in my mouth, enough to deter me from using it much more until a couple of years later. Nowadays such things are just line noise to me, but back then I remember being lightly concerned.
The essence of the sender/receiver proposal is essentially this: - first start with a sync function
- make it async by adding a continuation: - then curry it: - finally modify the curried variant to add another required evaluation round: The actual library uses structures with named methods instead of callables (so you would do operation.start() for example), plus a separate continuation for the error path (by having the receiver concept implement two named functions), and cancellation support. Also the final operation is required to be address stable until it is completed.The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).
The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.
> can avoid or defer a lot of the expected memory allocations of async operations
Is this true in realistic use cases or only in minimal demos? From what I've seen, as soon as your code is complex enough that you need two compilation units, you need some higher level async abstraction, like coroutines.
And as soon as you have coroutines, you need to type-erase both the senders and the scheduler, so you have at least couple of allocations per continuation.
I can't comment on this particular implementation but few years back I played around with a similar idea, so not quite 1-to-1 mapping, but my conclusion derived from the experiments was the same - it is allocation-heavy. Code was built around similar principles, with type-erasure on top of future-promises (no coroutines back then in C++), and work-stealing queues. Code was quite lean, although not as feature-packed as folly, and there was nothing obvious to optimize apart from lock-contention, and dynamic allocations. I did couple of optimizations on both of those ends back then and it seemed to confirm the hypothesis of heavy allocations.
I have only played very little with it and I don't have anything in production yet, so I can't say.
I did manage to co_await senders without additional allocations though (but the code I wrote is write-only so I need to re-understand what I did 6 months ago again).
I recall that I was able to allocate the operation_state as a coroutine-local, and the scheduler is node based, so the operation_state can just be appended to the scheduler queue.
You still do need to allocate the coroutine itself, and I haven't played with coroutine allocators yet.
Thanks, your comment has explained this better than the article
And it does look like an interesting proposal
The article is one-level up where it is both using higher level combinators and the pipe syntax for chaining sender and receivers. I do find that hard to reason as well.
My reduction to continuations is, I think, derived form Eric Niebler original presentation where he introduced a prototype of the idea behind sender/receivers.
Very helpful comment
With all the changes in C++, it always makes me wonder how developers these days reason about what the code is actually going to compile to and perform like. I feel like I have a good enough understanding of C and of older C++, but there's a constant influx of new syntax and new concepts in C++, and for a language that is supposed to be for systems programming, much of that seems so far away from "the machine".
> it always makes me wonder how developers these days reason about what the code is actually going to compile to and perform like
What will it compile to? Check out Compiler explorer [0].
What will it perform like? Use benchmarks [1] [2]. Remember that benchmarks heavily depend on what system you're using. Benchmarks for generically-compiled software on modern hardware will look very different than benchmarks for the same software but hyper-optimized to run on 10-year-old hardware.
So: if it's not tested, it's not Engineered.
For tests, I strongly prefer GTest [3], for a fairly consistent API across benchmarking, testing, and mocking.
> there's a constant influx of new syntax and new concepts in C++
Yes, but you don't have to use all of it. You can still use older C++ if you really want to. I wouldn't recommend it though. I think the "sweet spot" right now is around C++17. It's got quite improved safety compared to "old" C++ (say... pre C++11) and is fairly easily understandable if you're coming from "old" C++.
[0]: https://gcc.godbolt.org/
[1]: https://quick-bench.com/
[2]: https://github.com/google/benchmark
[3]: https://github.com/google/googletest
C++ has two ways of naming things: `std::incomprehensible_long_name` and `|`.
It's funniest when they're making keywords.
"Hmm, we need a new keyword to express this complicated idea about how geese move, in other languages they seem to use the keyword fly"
A1: Just re-use this existing four letter keyword 'swim'. Yeah, technically a goose can also swim but that's different, and the ideas aren't similar, and the implementation is entirely different, but this way we didn't need a new keyword so it's less work for a compiler right?
A2: Simple, new keyword complicated_goose_motion - why are people not happy with that?
At some point a noob will ask "Hey why can't we just name it `fly` like in Other Language?" and they will be ridiculed because of course several C++ companies have used the word fly as an identifier in software, and so reserving that word would incur a slight annoyance for them, whereas just forcing either A1 or A2 avoids a little work for those companies and is thus better...
Please, it would obviously be called co_fly.
I love C++ for the power it gives me, but boy do I hate reading C++ code. I know most of these things are for historical reasons and/or done because of parser compatibilities etc. but it's still a pain.
I used to live and breath C++ early 2000s, but haven't touched it since. I can't make sense of modern C++.
> I can't make sense of modern C++
A lot of it is about making metaprogramming a lot easier to write and to read.
No more enable_if kludges since if constexpr (and concepts for specific stuff); and using concepts allows to better communicate intent (e.g.: template<typename I> can become template<std::integral I> if you want the template to be used only with integer types, and so on)
Thankfully, you can still write C++ just fine without the "modern" stuff and have not only readable code, but also sane compile times. The notion, explicitly mentioned in the article, that all this insane verbosity also adds 5 seconds to your build for a single executor invocation is just crazy to me (it is far longer than my entire build for most projects).
I am confused. Out of curiosity WDYM by 5 seconds being far longer than your entire build for most projects? That sounds crazy low.
It's not crazy, it's just what happens if you write mostly C with some conveniences where they actually make sense instead of "modern C++". I generally write very performance sensitive code, so it's naturally fairly low on abstraction, but usually most of my projects take between one and two seconds to build (that's a complete rebuild with a unity build, I don't do incremental builds). Those that involve CUDA take a bit longer because nvcc is very slow, but I generally build kernels separately (and in parallel) with the rest of the code and just link them together at the end.
Sure, C++ is heavy for compilation, there's simply more by the compiler to do, but code repository building under 5 seconds is at the very low end of tail so making the point about someone bearing with the 5 seconds longer build time is sort of moot.
I wrote a lot of plain C and a lot of C++ (cumulatively probably close to MLoC) and I can't remember any C code that would compile in such a short time unless it was a library code or some trivial example.
You may want to watch some of Herb Sutters videos. He is one of the few sane people left in the upper echelon of C++ supporters
Only if by power you mean performance. Otherwise C++ is not a very ”powerful” language.
I’d like to see an example of a task that can be done with less verbosity in C++ than say, Python, using only the standard library
Something more complicated maybe ? Like say parse arguments from a command line ?
This post is a prime example of the latter syntax which looks like a crow was jumping on a snow, and is equally readable.
At the end they mention this text:
The authors and NVIDIA do not guarantee that this code is fit for any purpose whatsoever.
And say that it worries them. This is actually a warranty disclaimer (the warranty of fitness for a particular purpose) and has to be written like this to be effective. So I would not read anything into it
Not only that, almost every software license (FOSS or proprietary) has a similar clause (often in all-caps).
It's funny because I remember the first time I tried Linux (Debian) nearly 25 years ago, that "NO WARRANTY, EVEN FITNESS FOR A PARTICULAR PURPOSE" warning in all caps really did leave a bad taste in my mouth, enough to deter me from using it much more until a couple of years later. Nowadays such things are just line noise to me, but back then I remember being lightly concerned.
Is it just me or are the code examples of the executors absolutely unreadable/comprehensible without reading it 5 times?
Even with different formatters I'd much prefer the tbb variant.