4 ms·
> It takes more than one clock cycle to determine the next task that we're going to resume execution for and then actually resume it. Not really, if you just i
by tomp 8y ago
> It takes more than one clock cycle to determine the next task that we're going to resume execution for and then actually resume it.
Not really, if you just implement a round-robin scheduler and if none of the fibres are actually blocked (i.e. if they just yield).
Artificial benchmark? Sure. But there's no way you could ever approximate this with OS threads, even if the user-space code/threads themselves do no useful work.
- wahern 8y agoThe difference between stackful coroutines (i.e. fibers in this case) and Python-style coroutines is that Python's coroutines need to rebuild the stack on every resume, whereas resuming a fiber is basically a goto. The cost of yielding and resuming a coroutine in Python is O(N) for the depth of the call chain, but O(1) for fibers. So as you say, a simple scheduler that just walks a linked-list could resume a stackful coroutine in a few instructions, plus the cost of restoring hardware registers (which is the same cost as a non-inlined function call), and the latter is easily pipelined so would take fewer cycles than instructions.
- tomp 8y agoIndeed, a highly-optimized scheduler is basically the same as looping through an array and calling virtual methods of each object. Extremely cheap.