I’d like to make a portion of my game utilize multiple cores. This portion of the game doesn’t make any calls to Unity, so Unity’s non-threadsafe-ness isn’t an issue. I’ve actually parallelized this same code in C++. I have a C# version of the code, though, which I’d like to use so that I don’t eliminate the possibility of the web player; I used to use a .dll of the C++ code.
Anyhow, I’ve been using System.Threading and creating my threads that way, but in the task manager, it appears that only one core is being used. So, did I make some sort of error in the code translation, or do the System.Threading threads all live on the same core? If they do live on the same core, what other approaches are there to threading which would use the multiple cores?
XNA 4.0 looks like it has some nice things with parallel foreach, which is basically what I need, but it doesn’t look like that’s what Unity uses (at least 2.6, though I’ll be upgrading to 3.0 soon).
For parallel code you need to write distinct threads that run their respective functions then it will work in parallel given you don’t force them to wait most of the time through mutexes or locks.
I realized I meant to say .NET 4.0 and C# 4.0, not XNA, but the answer is probably the same.
I have threads running their respective function, it’s just that they all seem to be lumped onto one core, so it’s not true parallelism, and I’m not getting any performance gain. So are you saying that System.Threading threads should allow threads to go onto multiple cores? I could have a mistake somewhere else, but I’d first like to make sure that System.Threading does indeed allow for the OS to place the threads onto multiple cores.
It was indeed problems of my own creation, and I found and destroyed them, so now I have speedup!
However, my game now does not run in the web player. Do thread pools just not work in the web player? The game opens and runs, but the objects with the parallelized scripts are just frozen in place. This does not happen at all in the editor or in a standalone. I suspect it’s some restriction on the web player, but I wanted to confirm. I turn off the parallelization and it works fine.
Also, I see Application.isWebPlayer() in the documentation, but I don’t appear to have that function. Was this added in Unity 3.0? If it is a restriction, I’ll just special case it, so that I don’t have to remember to toggle a boolean in the code every time I build.
No problems here. If you’re accessing any of the Unity API in a thread, that will randomly fail, since it’s not thread-safe.
It’s actually a boolean rather than a function, but yes, it was added in Unity 3. You can use Application.platform instead, but it’s a little more cumbersome and will potentially fail if other web platforms aside from Mac/PC are added.
Thanks, I’m planning to upgrade to Unity 3.0 some time soon.
Also, the parts of the code I parallelized make no use of the Unity API whatsoever, so I’m pretty sure it’s not that. It’s all an external physics library, and I’ve already loaded in all of the relevant data from Unity before the threading starts; the parallelized portions are self-contained and don’t touch Unity or any Unity classes at all. I guess I should figure out how to view debug logs in the web player, then, because I do catch exceptions in such a way as to avoid deadlock, so it’s possible that some error is being thrown and the execution of the script is being terminated early. I just know that some things like loading DLLs don’t work in the web player, so I didn’t know if thread pools don’t work as well, or if it’s something particular about my approach.
I just went through my post history and realized I never resolved this thread, so forgive the resurrection, but in case anyone has a similar issue in the future:
Environment.ProcessorCount
That was the statement causing my problems. It’s not allowed in the web player. Fortunately, it does throw a catchable exception.