Open DXist opened 2 years ago
Generators are coroutines w/o schedulers, aka semicoroutines. I don't think it's a good idea to mix them up in a single problem, we can maybe define another one for generators
An interesting detail.
I renamed "coroutines" into "semicoroutines".
So coroutine based prime sieve is expected to reveal the overhead of coroutine scheduler, isn't it?
Separate generator focused problem will be fair in this case.
Also for couroutines it's interesting to compare single threaded and multi-threaded schedulers.
Lua scheduler is single threaded. Tokio in Rust is multi-threaded by default but can be configured to use only current thread.
In this case there is no need to use atomic primitives and pay for cross cpu synchronization.
Indeed, didn't notice that
Rust has an unstable feature for generators/semicoroutines - https://doc.rust-lang.org/beta/unstable-book/language-features/generators.html
It's interesting to see how it will compare to async based implementations.