Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My tutorial and take on C++20 coroutines

scs.stanford.edu

Post reply on HN
Print view View original

81–90 of 144 posts

Re: My tutorial and take on C++20 coroutines

#81

Post by gpderetta »

jcelerier wrote: post #63
oivey wrote: post #20

Earlier quoted context omitted.

Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. If you limit mutation and try to reduce the long reaching accessibility of variables then I think they’re generally very understandable, especially compared to other concurrency/parallelism paradigms.

> Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. but how often do you need concurrency and parallelism outside of handling network requests and performing some complicated math algorithm (which may be in a lib that you don't touch anyways, e.g. FFT>) ? e.g. most UI code has to run on the main thread due to macOS / Windows limitations, and in most UI software it is extremely rare t…

Coroutines are not really for parallelism. I doubt you'll see them much around math heavy code. Possibly if someone implements some Cilk style work stealing executor...

Re: My tutorial and take on C++20 coroutines

#82

Post by Cyph0n »

lights0123 wrote: post #74
pjc50 wrote: post #48

Earlier quoted context omitted.

This is all down to not having a "managed runtime", so it has to be shoehorned into the environment available where you have a stack, a heap, and that's basically it.

For me coming from Rust, this just seems way overly complicated to me. Rust's async doesn't even need a heap to work: https://lights0123.com/blog/2020/07/25/async-await-for-avr-w...

Great article, thanks for sharing!

Re: My tutorial and take on C++20 coroutines

#83

Post by snarfy »

nly wrote: post #19

Some notes: - C++20 coroutines are stackless , meaning that multiple coroutines will share a single OS thread stack. This is non-obvious when you first look in to them them because coroutines look just like functions. The compiler does all the work of ensuring your local variables are captured and allocated as part of the coroutine yield context, but these yield contexts are not stack frames . Every coroutine you inv…

It seems really dumb that they are stackless. If you are saving/restoring the stack pointer anyway in your yield routine it's trivial to set it to a block of memory you allocated in the initial coroutine creation.

Is there no setjmp/longjmp happening? Are C++ 20 coroutines all just compiler slight-of-hand similar to duff's device with no real context switching?

Re: My tutorial and take on C++20 coroutines

#84

Post by bluGill »

oivey wrote: post #27
Davidbrcz wrote: post #21

Earlier quoted context omitted.

C++ coroutines as they are in the standard are not really intended to the everyday programmer (1), but rather for library implementers who will use and abstract them into higher level features. 1: like most of C++ one would way

Ultimately, I think the simultaneous complexity and lack of built in functionality will limit how often people end up using this new part of the standard. I can use coroutines to write high performance, parallel code in other languages without being a mythical ~library implementor~. I usually even write libraries in those languages.

Doing things right takes time. This is one step in making co-routines useful. Library authors now have something to work with to figure out what the next part of the C++ standard is. Expect standard library support in C++ in either c++ 23 or 26.

Re: My tutorial and take on C++20 coroutines

#85

Post by gpderetta »

snarfy wrote: post #83
nly wrote: post #19

Some notes: - C++20 coroutines are stackless , meaning that multiple coroutines will share a single OS thread stack. This is non-obvious when you first look in to them them because coroutines look just like functions. The compiler does all the work of ensuring your local variables are captured and allocated as part of the coroutine yield context, but these yield contexts are not stack frames . Every coroutine you inv…

It seems really dumb that they are stackless. If you are saving/restoring the stack pointer anyway in your yield routine it's trivial to set it to a block of memory you allocated in the initial coroutine creation. Is there no setjmp/longjmp happening? Are C++ 20 coroutines all just compiler slight-of-hand similar to duff's device with no real context switching?

The compilation model is implementation defined, but yes, the expectation is that they compile down to a switch-like explicit state machine.

The advantage is that the worst case frame size is bounded, small and computable at compiletime.

Stackfull coroutines are of course more powerful and have, IMHO, better ergonomics.

Re: My tutorial and take on C++20 coroutines

#86

Post by pjmlp »

jcelerier wrote: post #14
creedor wrote: post #4

I'm a bit confused by all of this. The idea of coroutines existed since the 60's. Then we came up with OOP that tries to combine function + data. And now we abolished this, are back at only functions and are now solving the 'state capture' problem for functions again with: Coroutines? How does the history of programming paradigms/patterns make any sense? :) Good article though.

> . And now we abolished this, ... no. coroutines are not supposed to be used in, like, more than an extremely small fraction of your codebase if you want to keep your code understandable

Ideally, but they taint everything they touch, that is why in C# I always start them from some point with Task.Run(), or leave it for the event and request handlers.

Re: My tutorial and take on C++20 coroutines

#87

Post by b0sk »

dilawar wrote: post #56

I see they are excellent for concurrent programming but is it possible to utilise all cores of processor effectively with coroutines?

Not necessarily. Concurrency is generally not parallelism.

Coroutines help solve IO-bound issues - a long networking API call doesn't block your program. You can continue doing other things. The side-effect of which may use all your cores efficiently but that's not the primary goal.

Re: My tutorial and take on C++20 coroutines

#89

Post by swagonomixxx »

bluGill wrote: post #84
oivey wrote: post #27

Earlier quoted context omitted.

Ultimately, I think the simultaneous complexity and lack of built in functionality will limit how often people end up using this new part of the standard. I can use coroutines to write high performance, parallel code in other languages without being a mythical ~library implementor~. I usually even write libraries in those languages.

Doing things right takes time. This is one step in making co-routines useful. Library authors now have something to work with to figure out what the next part of the C++ standard is. Expect standard library support in C++ in either c++ 23 or 26.

I agree with GP, I feel a similar disdain when I hear that features that are merged into the standard are for the "library implementors". Boost.Coroutine and Boost.Asio have been around for how long? At least a decade? I think there has been more than enough experience with coroutines and async programming to get coroutines in standard C++ done so that at least the "average" C++ programmer can grok them.

Re: My tutorial and take on C++20 coroutines

#90

Post by nickysielicki »

superkuh wrote: post #88

As a developer, when you decide to use bleeding edge C++?? extensions keep in mind that when you do so you're making it much, much harder to run any of your code on a distro more than 4 years old. Is it worth it?

Similarly, as a user, keep in mind that when you use a 4 year old distro, it becomes much, much harder to run any software that has adopted new C++ features.
Post reply on HN