Close performance gap between bevy_tasks and rayon

[alice-i-cecile]

• One is that their executor spins a little more waiting for another task to be ready.
• For par_for_each stuff, it wakes new threads faster as async executor limits to waking one thread at a time.
• When it forks (splits current task in 2) it runs one on the current thread and only spawns a task for the other task.

There's probably some other microoptimizations too, but I think the above are the lowish hanging fruit.

From @hymm on Discord.

[mockersf]

is there a way to measure this performance gap before trying to optimise for it?

[Kanabenki]

It seems rayon already has a suite of bench tests in rayon-demo, we could try to adapt some of the relevant ones to use bevy_tasks instead and compare the runs with something like Criterion.

[dmyyy]

There's also @Elabajaba's executor bench here which shows rayon to be 2x faster than bevy_tasks.

[james7132]

As discussed on #6941, I'm more and more leaning towards reintroducing rayon as a base for all of our multi threaded processing. This may change with smol-rs/async-executor#93, but there is also a number of optimizations that rayon has made that is non-trivial to port to async-executor.

Since the introduction of ECS v2, Rayon has added support for wasm, and even has a version that supports web worker based multithreading. There remains the question of how we'd handle async tasks, which remains to be seen, but there are definitely a few options out there that merge tokio and rayon together, so it definitely seems doable.