Thanks for using a working microphone. Not all heroes wear capes
@yephick
2 жыл бұрын
Yet another coro video that can be summarized to a simple "just don't"
@BartoszGrabias
Жыл бұрын
Hi! At 27:32 you’re showing to return „suspend_never” from final_suspend(), however it is UB (at least according to cppreference) to resume a coroutine after final_suspend is called. Great talk, I was looking for an example of actual implementation of coroutine executor!
@doublesman0
2 жыл бұрын
glad there are now modern features from c# etc. available in c++.
@yevgenyn
2 жыл бұрын
Maybe it was not a very good example of how to show the benefits of coroutines. It was quite obvious that it made no sense to introduce such additional complexity to get almost no performance gain. The manual batching algorithm looked much easier to understand and maintain, which performance would be just fine especially if it would call .reserve() before inserting new vector elements. Great video anyway, showing everybody that many factors must be considered before using new hyped tech in your production code!
@MakersF
2 жыл бұрын
[I'm the author] Thanks for the feedback. I definitely agree that I wouldn't implement such a solution for the problem at hand, in isolation. But this talk shows how to implement a library that enables such feature, so of course it's quite complex. Regular user code would simply use the batcher, executor and task type implemented already by the library, and in such cases I think the trade-off becomes much more reasonable, especially as the complexity of the code grows, since the corobatch solution mimics the natural way of writing the code, while the algorithm one is significantly different. The equivalent comparison would be not to have the header available and having to implement all of the used functions. BTW I started investigating this (well before coroutines were standardized) problem because I faced multiple times that the code written in production, in different code bases and by different teams, was doing the trivial, unoptimized for-loop instead of the algorithm version, and resulted in performance issues in some cases. I hope to see with some production experience whether an approach similar to this helps in avoiding such cases or not.
@MaceUA
2 жыл бұрын
afaik pop_next_coro doesn't need to return an optional -- coroutine handles can be null, so we can just return a null handle instead of nullopt
@MakersF
2 жыл бұрын
[I'm the author] Correct. But I like to treat pointers as always valid, and make it explicit when they are not. Otherwise every time I use a pointer I need to check if it's null or not. Alternatively, I could also have used std::noop_coroutine in the pop_next_coro and return an handle which is always valid (although implenting the run function would have been more complex then)
@stavb9400
2 жыл бұрын
Sorry but I don't get it how creating 3 different classes is more readable than manual batching
@mysund
2 жыл бұрын
There is a lot of talk about the compiler, e.g. at 16:50 18:30 19:40. Must be a runtime error on behalf of talker :)
@MakersF
2 жыл бұрын
[I'm the author] When I was saying "the compiler is going to X" I meant that the code generated automatically by the compiler when transforming coroutines in just regular code will do X. I hope this helps making sense of that section!
@yanushkowalsky1402
Жыл бұрын
Thanks for the talk. Doesn't this prove that cpp coroutines are low level blocks that shouldn't be used to write programs like these? Much of this complexity should be abstracted away.
@kwinzman
2 жыл бұрын
Wait, isn't this very similar to what the "ranges" library was supposed to solve? Or does that not fit the coroutine paradigm? I am confused.
Пікірлер: 13