You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way query iteration is currently implemented leads to inefficient code. On my machine, iterate_mut_100k runs in around 29us. However, running the same iteration through explicit archetypes leads to much better performance at around 10us. Looking at the assembly, the difference is loop unrolling and better auto-vectorization.
From previous experience writing code like this in Rust, I'd say that the issue is caused by having to deal with case where we need to move to the next archetype when iterating over the query. I haven't yet tested, but I'd expect similar or even worse performance were the archetypes Iterator::chained together.
Here is the code that runs ~2.9x faster:
fniterate_mut_100k_archetypes(b:&mutBencher){letmut world = World::new();for i in0..100_000{
world.spawn((Position(-(i asf32)),Velocity(i asf32)));}
b.iter(|| {for archetype in world.archetypes(){iflet(Some(mut pos),Some(vel)) = (archetype.get::<&mutPosition>(), archetype.get::<&Velocity>()){for(pos, vel)in pos.iter_mut().zip(vel.iter()){
pos.0 += vel.0;}}}})}
I'm opening this issue to start a discussion about how some of this performance could be tapped into without having to rely on explicitly iterating through all the archetypes.
The text was updated successfully, but these errors were encountered:
I'm not overly concerned about this because I think the difference will disappear outside of trivial loop bodies (i.e. in real use), but improvements would certainly be welcome.
I mostly agree about real use, but there are many cases where this would be useful. For example, in forma there's a decently complex rasterization pipeline that relies on rustc/LLVM auto-vectorizing every line. (of which there can be many)
I'll try to see if I can get LLVM to spit out some interesting optimization remarks that might be useful and thanks for the timely reply!
The way query iteration is currently implemented leads to inefficient code. On my machine,
iterate_mut_100k
runs in around 29us. However, running the same iteration through explicit archetypes leads to much better performance at around 10us. Looking at the assembly, the difference is loop unrolling and better auto-vectorization.From previous experience writing code like this in Rust, I'd say that the issue is caused by having to deal with case where we need to move to the next archetype when iterating over the query. I haven't yet tested, but I'd expect similar or even worse performance were the archetypes
Iterator::chain
ed together.Here is the code that runs ~2.9x faster:
I'm opening this issue to start a discussion about how some of this performance could be tapped into without having to rely on explicitly iterating through all the archetypes.
The text was updated successfully, but these errors were encountered: