One of the bullet points for unity 5 is "job queues", Does anyone have any info about this? Would it allow me to submit a job from a background thread to the UI thread for example?
I am very curious about this, because what I've heard is that Unity 'automagically' handles it... And I'd like to know more, and I'd like to have at least some control myself
I would also like to know more about the multithreaded job system too! Which parts of the engine will it affect, how it will work? Please some unity folk stop by, don't let us die dry! Awesomeness!!!
I'd also like to know more, how does this work and which areas are affected? (PhysX 3.3 is multithreaded, but what more? And is that related to this 'job queue'?)
I expect it will work in a similar fashion to Coroutines, i.e. you define a bunch of short tasks that you want to run in the background, fire them off to Unity's job queue, and then Unity handles all the scheduling and data synchronization and all the other ugly parts that come with multithreaded programming. See the Quartz.NET library for an example of how it would look.
To the look of the videos it looks pretty much like that. At least telling Unity "I need this to run in the background with this priority" would be more than awesome. Or a bit more advanced like distributing a task over different threads (why not). At least I know it'll be running on a different thread that the main thread which is all I need.
The only thing I've worked with that I've seen (so far) that uses what is called "JobProcess.exe" is baking light maps. There may be one or two of these running at a time, but all 8 cores of my CPU are running. Of course, it runs the settings you designate. (info from my experience in Unity 5 (closed) beta)
I think people are reading too much into that headline (and the wording is not the best). What it means is that internally more stuff is multithreaded now (culling, navmesh, ...). Nothing to do with your own script code, though I think folks are looking into how to expose that to scripts (but not in 5.0).
Also, note that with a job system there usually is no task-dedicated threads like a 'UI thread' and so on - it's more of a threadpool style system.
Why not expose a similar approach for scripts? All i want to is: Updating transform positions/rotations of 5000 object in a multiithreaded manner. and by that i mean the loop that updates them one by one is located in update() and i find it ridiculous to see the lag happens in this simple task. I know what you may think, 5000 is not a large number. Well it is a huge number, if your positions are being read from a Vector3[5000] array. It is not a calculation, but it is actually a memory bound problem where if chunks of that array is updated in parallel, it would drastically increase the speed. now if there was a way to pass the objects to unity internal and let it be done in a thread pool, that would have been great. This is a realistic simulation that we're talking about and accuracy is everything to us. I have been working with my team to accquire unity 5 licenses and we actually were hoping this would be available. but if this is not even intended, then I think Aras is right and the wording has put us and many others in a technical misunderstanding. But thank you for the clarification.
Because nothing happens by itself, someone needs to do it Some folks here are thinking about how to expose that, but nothing that we "can ship" yet.
How about creating a new YieldInstruction, that I can flag as complete from a background thread, so a ui coroutine can yield waiting for a background thread.
Letting us create and control our own UnityEngine.AsyncOperation instances would be perfect for this, and useful for quite a few things, I think...
Here is another idea: Code (CSharp): private int MyBgFunc() { // this gets executed in a background thread Thread.sleep(10); return 10; } private IEnumerator MyCoroutine() { // this starts a new thread var unitythread = StartThread(MyBgFunc); yield return unitythread; // this yields until the thread is done Debug.Log("The tread result was " + unitythread.result); } So StartThread would look similar to StartCoroutine, and returns a yieldinstruction, once the thread finishes, the yieldinstruction is marked complete. Even something this simple would be immensely useful for those of us making procedural terrain and other heavy background math.
wtf? is this guy really applying for a job in a job queue thread about multi-threading? I guess if you are that guy, watching this video goes a long way: