07-06-2021, 01:28 PM
Yeah I'm unsure where specifically the performance differences came from in my case. I traced the code around BurstConstraintsImpl.cs and the Evaluate & Apply calls.
I found an interesting difference between PC and Android builds, which I think have something to do with the thread pool of each device.
In the attaced image, the job scheduler is fast enough to queue up jobs much more densly on an android build with 4 worker threads.
Compared to the PC build, which runs 15 workers, jobs are scattered around a lot more. Looks like it's down to jobs being too small for the scheduler to queue them effectively before they finish work.
This aligns itself well with batching ideas for 7.0 you mentioned in the other thread!
I've played with the BurstSolverImpl.ScheduleBatchedJobsIfNeeded() number:
Going too high, like 128 for the PC build, would cause visible blue "strips" of denser work done, but overall slower Substep time.
While lower values like 4 gives me a strange result where during some frames I get faster substep time, and then slower on others, filled with thread idle time between each job.
(also note the Project samples have improved, so it may have been a bad build with some rogue settings. I have been trashing my checkout with a lot of test-changes last week..
)
![[Image: job-queue.png]](https://i.ibb.co/xhNQknw/job-queue.png)
I found an interesting difference between PC and Android builds, which I think have something to do with the thread pool of each device.
In the attaced image, the job scheduler is fast enough to queue up jobs much more densly on an android build with 4 worker threads.
Compared to the PC build, which runs 15 workers, jobs are scattered around a lot more. Looks like it's down to jobs being too small for the scheduler to queue them effectively before they finish work.
This aligns itself well with batching ideas for 7.0 you mentioned in the other thread!
I've played with the BurstSolverImpl.ScheduleBatchedJobsIfNeeded() number:
Going too high, like 128 for the PC build, would cause visible blue "strips" of denser work done, but overall slower Substep time.
While lower values like 4 gives me a strange result where during some frames I get faster substep time, and then slower on others, filled with thread idle time between each job.
(also note the Project samples have improved, so it may have been a bad build with some rogue settings. I have been trashing my checkout with a lot of test-changes last week..
)