Parallelize State call in ECM

[JShep1]

Ready for review. Below is a plot of 25 randomly sampled PostUpdate profiled points for both before and after this PR.

The before average timestep of PostUpdate was 33.095 ms and after average time for PostUpdate is 22.479 ms in the case of the shapes_population.sdf. This PR is primarily targeted for larger example and will not significantly affect smaller examples (if there are under 50 entity components, no speedup will occur at all due to the nature of the thread spawning in this PR).

My RTF before this PR after 2 minutes of running shapes_population.sdf was 0.602% and after the PR I am getting about 0.669% RTF.

I'm going to experiment with the the number of threads and the number of components each thread handles to see if I can tune these two parameters to get a more optimized RTF. I don't think changing the max thread count to anything higher than std::thread::hardware_concurrency() (the max suggested threads that the hardware supports) would speed up anything, this would likely just bottleneck any additional threads and schedule them in when it puts other threads to sleep. Perhaps we could see some speedup with the amount of entity components each thread will run at minimum, but I'm not so sure this would make a huge difference either, it would only affect scenes in which there are between componentsPerThread and componentsPerThread * maxThreads entity components.

[iche033]

Here's what I got comparing performance of the State function before (top image) and after (bottom image) the change:

This is from running the shapes_population.sdf world. It does look there it shaved a few ms off the State function. When running with TPE plugin, the RTF before the change is 1.4x% and after is 1.8x%.

Note careful about using remotery for profiling. I noticed that since new threads are spawned every iteration, it made remotery a bit laggy and unresponsive sometimes.

[JShep1]

Good to see that you're seeing improvements... I guess Remotery was a bit wonky for me given all the threads spawning. I'll clean up the logic and make it more generalizable and get the PR in for review soon.

[iche033]

by the way, I wonder if it's possible to reuse threads, e.g. store in member variable?, and have them wait on a condition_variable until there's work to do.

[JShep1]

by the way, I wonder if it's possible to reuse threads, e.g. store in member variable?, and have them wait on a condition_variable until there's work to do.

That's also what I was thinking and was going to attempt something like that. It would certainly reduce noise in Remotery as well as cut down any overhead from spawning so many threads every iteration.

[iche033]

I tested by adding and deleting objects in a shapes.sdf, and spawning objects from fuel and it seems to be work fine for the case of single thread.

Interestingly, I tried shapes_population.sdf and noticed that a sphere is missing (sphere_534):

I also tried generating a shapes_population.sdf world with n set to 100 and I see a couple of models missing. Do you see the same issue?

[JShep1]

I also tried generating a shapes_population.sdf world with n set to 100 and I see a couple of models missing. Do you see the same issue?

Good catch, took me a little bit to find the bug, but I resolved it here: 0ba4684

[iche033]

The number of objects in shapes_populations.sdf are now correct for me.

I'll leave it to you and @chapulina to decide on the number of threads to use. Otherwise the PR looks good.

[chapulina]

Thanks for the improvements!

[chapulina]

The ABI checker is having the same old false positive. All other CI looks good. Merging!