On Mon, Mar 14, 2022 at 10:31:47AM +0100, Paolo Bonzini wrote: > However, there are no ramifications to actual coroutine code, except > for the template syntax "CoroutineFn<return_type>" for the function and > the mandatory co_await/co_return keywords... both of which are an > improvement, really: the fact that a single function cannot run either > inside or outside coroutines is checked by the compiler now, because > qemu_coroutine_create accepts a function that returns CoroutineFn<void>.
Yeah, these are nice. > One important difference is that C++ coroutines allocate frames on the > heap, and that explains why performance is better in /perf/nesting, > which has to do many large memory allocations for the stack in the other > two backends (and also a makecontext/swapcontext in the ucontext case). > C++ coroutines hardly benefit from the coroutine pool; OTOH that also > means the coroutine pool could be removed if we went this way. Removing the pool would be nice. > Overall this was ~twice the amount of work of the C experiment, but > that's because the two are very different ways to achieve the same goal: > > - the design work was substantially smaller in the C experiment, where > all the backend does is allocate stack frames and do a loop that invokes > a function pointer. Here the backend has to map between the C++ concepts > and the QEMU API. In the C case, most of the work was really in the > manual conversion which I had to do one function at a time. > > - the remaining work is also completely different: a source-to-source > translator (and only build system work in QEMU) for the C experiment; > making ~100 files compile in C++ for this one (and relatively little > work as far as coroutines are concerned). > > This was compiled with GCC 11 only. Coroutine support was added in > GCC 10, released in 2020, which IIRC is much newer than the most recent > release we support. Using C++ coroutines is likely to be lower risk than maintaining our own C coroutine source-to-source translator. On the other hand, it exposes QEMU developers to C++ whether they like it or not so it may not be popular. If we can reach a consensus about C++ language usage in QEMU then I'm in favor of using C++ coroutines. It's probably not realistic to think we can limit C++ language usage to just coroutines forever. Someone finds another C++ feature they absolutely need and over time the codebase becomes C++ - with both its advantages and disadvantages. I'm not sure what the best solution is but this sounds like a recipe for an identity crisis with the potential to cause friction for years. From that perspective I feel it's better to allow C++ and get over it although what I'd really like is just C++ coroutines and nothing else :P. To add some more detail, although you can write C in C++, it's not idiomatic modern C++. The language lends itself to a different style of programming that some will embrace while others will not. It will be a bigger impedance mismatch than anything currently in the codebase (e.g. glib vs non-glib code). On the other hand, a number of projects have already gone through a transition like this (gcc, gdb, ...). Maybe we can learn from their mistakes? Stefan
signature.asc
Description: PGP signature