Coroutine based coro-prime-sieve for Rust

[DXist]

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.

[hanabi1224]

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

[DXist]

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.

[DXist]

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.

[hanabi1224]

it's interesting to compare single-threaded and multi-threaded schedulers

I believe this has already been covered. e.g. 3.rs for single-threaded tokio, 3-m.rs for multi-threaded tokio, 1.kt for single-threaded kotlin coroutine, 2-m.kt for multi-threaded kotlin coroutine, etc.

[DXist]

Indeed, didn't notice that