I have been reading this paper: https://www.open-std.org/jtc1/sc22/wg21 ... 876r15.pdf. I'm not very proficent in the world of coroutines yet. I have read a lot but never used it, and after reading the paper and some other Internet resources and understanding the difference between stackless and stackful coroutines, I have some questions:
Is moving in and out of coroutines (resuming/yielding) faster than switching between fibers? It doesn't look like fibers are slower, because in both cases, the execution context (the "frame" for a coroutine, and the full stack for a fiber) are in the heap, and "switching context" is basically modifying the frame pointers and program counter to point to the new control, so I don't see how the performance can be different.
NOTE: I understand that whatever mechanism is used to implement fibers in C++26 (or later) would be inspired by the boost::fiber implementation, and so I'm talking like fibers were already a thing in C++.
Why would you need coroutines if you have already fibers? Fibers looks like more powerful than coroutines (you can switch between fibers at any point in the program, but you can only transfer control from a coroutine, and never from an auxiliary non-coroutine function). It's said that coroutines doesn't need a scheduler while fibers does, but, with coroutines you can emulate a scheduler in case you need it (and the default transfer-control-to-the-coroutine-caller can be thought as a kind of default scheduler: schedule next the caller), but the fiber scheduler can also be personalized to use the strategy you want, so I don't really see any difference between both.
If there are more differences I'm not seeing now, I'd like to know which uses cases are those where coroutine shines, in the sense that doing the same with fibers will be too much pain in terms of performance or design.
I have been reading this paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0876r15.pdf. I'm not very proficent in the world of coroutines yet. I have read a lot but never used it, and after reading the paper and some other Internet resources and understanding the difference between stackless and stackful coroutines, I have some questions: [list] [*]Is moving in and out of coroutines (resuming/yielding) faster than switching between fibers? It doesn't look like fibers are slower, because in both cases, the execution context (the "frame" for a coroutine, and the full stack for a fiber) are in the heap, and "switching context" is basically modifying the frame pointers and program counter to point to the new control, so I don't see how the performance can be different. [*][b]NOTE:[/b] I understand that whatever mechanism is used to implement fibers in C++26 (or later) would be inspired by the boost::fiber implementation, and so I'm talking like fibers were already a thing in C++. [*]Why would you need coroutines if you have already fibers? Fibers looks like more powerful than coroutines (you can switch between fibers at any point in the program, but you can only transfer control from a coroutine, and never from an auxiliary non-coroutine function). It's said that coroutines doesn't need a scheduler while fibers does, but, with coroutines you can emulate a scheduler in case you need it (and the default transfer-control-to-the-coroutine-caller can be thought as a kind of default scheduler: schedule next the caller), but the fiber scheduler can also be personalized to use the strategy you want, so I don't really see any difference between both. [/list] If there are more differences I'm not seeing now, I'd like to know which uses cases are those where coroutine [b]shines[/b], in the sense that doing the same with fibers will be too much pain in terms of performance or design.
Мобильная версия