Use single threaded executor in benchmarks and tests

[A-Walrus]

Objective

Fixes: #9838

Solution

Add single_threaded constructor for Schedule and use it in all benchmarks and tests.

[hymm]

You shouldn't make this change for any of those scheduling benchmarks. Those are specifically measuring multithreaded execution.

[hymm]

Can you also do a pass over the doc examples? Those get run during testing too. A lot of them are using Schedule::default.

[hymm]

Are you sure this should use the multithreaded schedule? This seems to just be testing the parallel iterator, which is unrelated to multithreaded scheduling.

[A-Walrus]

When I tried it with the singlethreaded schedule it didn't work... might have accidentaly uncovered a bug :P

[hymm]

I changed it to single_threaded on my machine and wasn't able to get it to fail. Could you double check and post the error if it does?

[A-Walrus]

Nevermind, changed it to single_threaded and it seems to work fine :P

[A-Walrus]

---- query::tests::par_iter_mut_change_detection stdout ----
thread 'query::tests::par_iter_mut_change_detection' panicked at 'A ComputeTaskPool has not been initialized yet. Please call ComputeTaskPool::init beforehand.', crates/bevy_tasks/src/usages.rs:28:33
Encountered a panic in system `bevy_ecs::query::tests::par_iter_mut_change_detection::propagate_system`!


failures:
    query::tests::par_iter_mut_change_detection

Got a failure for this test on the latest commit. Might be flaky...

[hymm]

I think we should make a multithreaded method that just wraps default to make it explicit we're choosing the multithreaded executor instead of leaving a comment.

[JMS55]

Same for rendering benchmarks, we want those to be multithreaded.

[A-Walrus]

Same for rendering benchmarks, we want those to be multithreaded.

@JMS55 Which rendering benchmarks are you referring to? I couldn't find any in the benches dir.

[JMS55]

Ah nvm then. All the rendering "benchmarks" are actually examples, not part of benches.

[alice-i-cecile]

This looks like the right setup now to me.

[alice-i-cecile]

@A-Walrus that CI failure looks like it might be real: can you reproduce it locally?

[A-Walrus]

@alice-i-cecile It's passing locally, but it has failed in CI multiple times. Weird

[hymm]

So we should either do like the error is saying and call ComputeTaskPool::init() before running the test or change par_for_each_unchecked_manual to call ComputeTaskPool::init(). I suspect the former is more correct, since that gives the user a chance to init the task pool how they like. We do call init when we're using the multithreaded executor. @james7132 do you have any opinion on this?