bklooster wrote
I just want to throw my support and state that we desperately want some multi threading in the spine runtime.
..
The problem I see is that this is using Spine-csharp which is very class/object heavy instead of array-based struct data that Jobs prefer.
Thanks for offering your help. Could you please re-write all of our runtimes using pre-allocated memory and in-place construction upon load-time? Just kidding 😉. We will not get rid of the current "one object per bone/constraint/etc" design until we replace it with a pre-allocated solution, which is planned but will not happen in 4.0 but some later version.
bklooster wroteThe problem I see is that this is using Spine-csharp which is very class/object heavy instead of array-based struct data that Jobs prefer.
You are mixing two things here. Using array based struct data, which actually means using Unity's Entity Component System to automatically re-arrange data of each struct, can improve cache locality. The benefit of using jobs is utilizing multiple cores instead of a single one to distribute workload. While good or bad cache locality will have an additional effect on each core's cache, it is a more or less orthogonal performance improvement. In general, the current object-based structure, with separate instance and shared data, is not expected to perform badly cache-wise in a multithreaded context (in regards to cache thrashing / false sharing).
Regarding using spine-csharp: we will always use the spine core-runtime of the respective language, not using spine-csharp is not an option here 🙂.
In general the best way anyone can assist us is by answering questions on the forums, which helps us devote more time to programming instead of replying to forum postings.
