Reason of passing `workerIndex` in jobs about bepuphysics2 HOT 1 CLOSED

Multiple threads accessing the same cache lines is a recipe for massive performance penalties. It's better for threads to work on independent data whenever possible. A common pattern is to have 'worker caches': memory that is modified by only one worker. A worker index lets you find that worker cache.

While you could do something similar with a job index alone, there are typically more jobs than workers within a single dispatch. Having to maintain a cache for every job just wastes memory and potentially increases the cost of any postprocessing over the set of caches.

The worker index being provided directly avoids the need for things like Thread.ManagedThreadId. Unlike Thread.ManagedThreadId, the worker indices cover the range [0, N) for a dispatch of N threads, so you can use them to index into different worker caches easily.

While the ThreadDispatcher assigns the worker indices at thread creation time, you can dynamically assign them at the start of each dispatch. In other words, you can think of IThreadDispatcher.Dispatch as a for loop from 0 to workerCount. I'm not familiar with unity's job system, but presumably there's some type of parallel for loop available.

(It's worth noting that the worker index is not required to map perfectly to a specific OS thread. It's nice where possible, since the OS tends to not shuffle threads between cores every half millisecond, and you'll probably get more cache hits compared to a version that has different thread-workerIndex mappings every dispatch, but the library jumps through some hoops to limit the number of dispatches. Much of the solver, for example, is one giant dispatch that manages its own scheduling.)

from bepuphysics2.