Will Unity 5 be multi-core?

I can comment on the "new multithreaded job scheduler" feature in Unity 5.0. We rewrote the multi-threading system used by the engine to be much smarter in how it manages tasks and dependencies between them.

Basically, in Unity 4.x, multi-threaded tasks in Unity (such as Skinning, Animation, Particles, Culling, etc) are implemented by having respective sections of the main loop when all the engine does at that point is calculating animation results, or skinning meshes, etc. It would then split those tasks into jobs which are are distributed among all CPU cores. This means that while the engine is handling tasks which are not multi-threaded (such as Physics in 4.x, game scripts, issuing render commands for a camera), all the other CPU cores are unused. So this means that essentially, Unity is only making use of all cores half of the time.

In Unity 5.x we introduced a new job scheduling system where jobs can be queued up and don't need to be finished before anything else actually needs the results. That means that for instance, we can queue a whole bunch of animation jobs, and then go straight to running game scripts - while the animation jobs are running on the other cores. Only when a script will actually access data which requires animation results (like access a transform component which is being used by the animation system), then it will block script execution until that task is finished. We can chain these dependencies so that for a skinned character for instance, several subsystems would queue dependent jobs, so that the rendering thread will wait for the skinning to be done, which will wait for the culling to be done, which will wait for the animation to be done, so that all these jobs would only have to be run when results are needed by something else. Overall, this allows much better utilization of CPU cores. In some examples we benchmarked, we were able to get frame durations down by 40% on a four core machine. These are constructed benchmark samples, real world performance gains will be lower - but I expect all content to be faster. Having multi-threaded physics in PhysX 3 will also add to that. On top of this, we will have a new timeline profiler, which allows you to inspect exactly what any CPU core is doing at any given point in time.

What this will not be is a new way to multi-thread user code. But, it *will* make sure that Unity will schedule other required tasks to run on other cores while your user scripts are running, so those cores are not idling like now.

This tech is pretty cool, I think we should write a blog post on it, showing some results (I'll check if someone wants to do it or if I'll find time to do it myself next week).

 

Work-stealing task scheduler? I have a dim recollection of an Xfest some years ago where the guys from Xbox ATG said it was the provably optimal approach.

 

That's kind of orthogonal to what Jonas described (you can build up a job scheduler with fine grained dependencies without work-stealing). But yes, our implementation is work-stealing as well.