bevy_rapier
bevy_rapier copied to clipboard
Use Bevy's parallel iterators rather than rayon
Rapier uses Rayon's parallel iterators to parallelize the engine (through the macros par_iter! and par_iter_mut!, which either calls .iter() or .par_iter() (or the mutable equivalents).
But Bevy also has parallel iterators: Query has .par_iter() and .par_iter_mut() and it uses Bevy's own runtime to parallelize the queries.
Are there plans to make use of this?
A potential issue is that QueryParIter oddly doesn't implement Iterator. In this example one sees that it's expected to write
sprites
.par_iter_mut()
.for_each(|(mut transform, velocity)| {
transform.translation += velocity.extend(0.0);
});
Rather than
for (mut transform, velocity) in sprites.par_iter_mut() {
transform.translation += velocity.extend(0.0);
};
Which I don't know why exactly; but other than that, it seems in principle possible to have a pluggable backend for parallel iteration.
(I opened this issue here because I think it only makes sense to expose this on bevy_rapier but maybe it should be moved to the main Rapier repository)
This is a bit more difficult because it'd have to be done in the rapier repo rather than here, but maybe worthwhile? It is a bit hard to tell.
Something like this would have to be behind a feature flag - my game makes heavy use of async task pools to the point where using par_iter in a normal system is nearly always slower than a normal iter.
Now that's interesting. Do you know why this happens? Why is rayon's threadpool faster in this case?
@dlight It's not that one thread pool is faster than another's, I'm just using a lot of threads so adding even more will just hurt performance instead of help it.
Edit: I just realized I completely misread the issue. I thought you were saying to add more par_iters not switch them to bevy's. Please disregard my comments =)
This kind of change would need quite thorough performance comparison, both for high and low amount of objects, as well as contention test (when other systems are running)