Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

unity don't support multi-core CPU?

Discussion in 'Editor & General Support' started by czx_main, Jan 4, 2010.

Thread Status:
Not open for further replies.
  1. czx_main

    czx_main

    Joined:
    Feb 18, 2009
    Posts:
    172
    My computer:

    cpu :QuadCore Intel Core 2 Quad Q6600
    memory: 4G
    display: WinFast PX9600 GT(NVIDIA)
     

    Attached Files:

  2. Jessy

    Jessy

    Joined:
    Jun 7, 2007
    Posts:
    7,325
    No. Unity is a 32-bit app and it only uses a single core.
     
  3. czx_main

    czx_main

    Joined:
    Feb 18, 2009
    Posts:
    172
    :cry:
    but, I at my friend's notebook to found it can be use Dual-Core CPU. My friend's computer is MAC’s notebook
     
  4. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Actually not, Unity is fairly multi-threaded and runs on more than one core, but most of the heavy stuff can't really take advantage of that. So more than one CPU helps a little but not a huge amount. Also 32-bit vs. 64-bit makes zero difference in this regard. The operating system and how it schedules threads on which core can make some difference though.

    Games have been notoriously hard to make parallel anyway, though that seems to have been improving lately. It's quite possible to use your own threads if you have routines that are easily sliced up and can take advantage of multiple cores, but you can only touch thread-safe .net stuff when doing that, not any of the Unity-specific functions. Otherwise it crashes a lot.

    --Eric
     
  5. lazalong

    lazalong

    Joined:
    Oct 13, 2009
    Posts:
    139
    My game engine (OGE - see my signature) is a multi threaded engine.

    Trust me it is difficult. Especially if you try to be cross-platform.

    I don't know the underlying design of Unity but depending on how they did it they might be obliged to rewrite nearly all to be a multi-threaded engine.
     
  6. magwo

    magwo

    Joined:
    May 20, 2009
    Posts:
    402
    For a vast majority of applications, one thread/core is perfectly fine, and it's SO nice to not have to think about multithreading issues when you're writing scripts and coroutines.

    If you're certain that you're CPU bound in Unity, usually the problem is that your scripts are doing things in wasteful ways such as finding objects in huge scenes and so on.

    From what I've seen, most Unity performance problems can be easily resolved by some simple algorithmic changes.

    I don't know what you're doing specifically, but if you find yourself in severe CPU performance problems, go over to the Unity iPhone forums and look at some of the crazy optimizations they do to make things run. Using iPhone-inspired optimizations, you should be able to do some crazy stuff on a normal PC.
     
  7. Tysoe

    Tysoe

    Joined:
    Jul 6, 2009
    Posts:
    577
    engines that use multi cores often just dump things like physics if the API supports it and streaming media so things like accessing the HD to load stuff doesn't effect the game too much.

    Don't know what unity does, if they update physx to a later version extra cores might be used automatically. I believe the current physx in unity is pretty sncient to allow for easy cross platform mac support.
     
  8. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    Since 2.6, Unity Pro is able to background load to use multicores better.

    But above that and a few other small things, multi core unleashing basically is restricted to System.Threading and you must not access the unity engine from those as unity is not thread safe. But you can have pure calculations offloaded that way.

    On mac its a whole different story because OSX works differently under the hood.
     
  9. czx_main

    czx_main

    Joined:
    Feb 18, 2009
    Posts:
    172
    so,if I use unity in OSX,Multi-core CPU you can use it?
     
  10. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    No you can not use it.

    OSX just handles threads and processes differently than Windows. But at the end of the day, unity runs pretty much in a single thread.
     
  11. Der Dude

    Der Dude

    Joined:
    Aug 7, 2006
    Posts:
    213
    To clarify:

    You can use your own threads. However your own thread should never call Unity functions like Rigidbody.ApplyForce. What you do here is you tell the Unity thread to do that for you in the next update.

    Of course when using threading regular synchronization problems arise and must be handled. Access to resources must be properly managed.

    I see a lot of potential in using multi-threading in Unity games because most scripts could run in parallel. Rarely do scripts share the same resources. And calculation-heavy stuff like AI, procedural Mesh generation could really profit from this.

    I've got a bit of middleware lined up that makes simple parallelization possible. All you do is use a different base class called ParallelBehaviour instead of MonoBehaviour. Then in the functions ParallelUpdate, ParallelFixedUpdate, ParallelX you write your code as you normally would.

    In addition to that (when its done), you'll be able to specify via Attributes if a certain script type needs to be executed before another type. Or if they can't run at the same time.

    I'm in the very early stage of development on this, but when doing stuff like calculating the roots of a bunch of numbers, performance increase is near 200%.
     
  12. magwo

    magwo

    Joined:
    May 20, 2009
    Posts:
    402
    Another thing to note about multithreading applications... it's still a bit of a catch 22.. because, at least if you're targeting a wide consumer audience.. you will be in a situation like this:

    1. Multi-core processors are modern and very fast.. and so they usually don't need the computational power of multithreading because they run your stuff exceptionally with one core.

    2. The processors that really need multi-threading due to poor performance (celerons, atoms, etc), only have one core, so it's pointless to multithread for performance reasons.


    Edit: I would say that... maybe 2-3 years from now it will start to become useful to multithread PC/Windows game engines for performance reasons. The market will then have a lot of slow but multicore processors around.
     
  13. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    I don't agree with that at all...processor speeds haven't been getting that much faster for the last few years (compared to earlier); the big increases have come from having more cores, to the point where a 4-core machine is now consumer rather than pro. It's getting quite hard to find a normal computer that isn't at least 2-core (and nobody games on netbooks)--all Macs have had a minimum of 2 cores for years now, with 4 and even 8 not being too uncommon, and probably 12 soon. It would be silly to ignore those cores when they are so common.

    It's already been useful for the last 2-3 years. You haven't had Quake 4, Unreal engine, etc. focussing on utilizing extra cores for no reason. Especially since gamers are more likely to have the latest processors anyway.

    --Eric
     
  14. Tysoe

    Tysoe

    Joined:
    Jul 6, 2009
    Posts:
    577
    I just upgraded from a single core to a dual core 3.0ghz that came out in 2007 and cost $50. Most gamers with a PC have at least dual core now.
     
  15. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    I thought a simple but real case might be useful here, instead of just theory. Therefore, a routine that fills a giant array with random values:

    Code (csharp):
    1. import System.Threading;
    2.  
    3. var threads = 16;
    4. private var numbers : float[];
    5. private var threadCounter = 0;
    6.  
    7. function Start () {
    8.     var arraySize = Mathf.Pow(2, 24);
    9.     if (arraySize % threads != 0) {
    10.         print ("Sorry, the array size must be evenly divisible by the number of threads.");
    11.         return;
    12.     }
    13.    
    14.     numbers = new float[arraySize];
    15.     var timeStart = Time.realtimeSinceStartup;
    16.    
    17.     for (i = 0; i < threads; i++) {
    18.         var thread = Thread(RandomFill);
    19.         thread.Start(i);
    20.     }
    21.    
    22.     while (threadCounter < threads) yield;
    23.    
    24.     print (Time.realtimeSinceStartup - timeStart);
    25. }
    26.  
    27. function RandomFill (iteration : int) {
    28.     var slice = numbers.Length/threads;
    29.     for (i = slice*iteration; i < slice*(iteration+1); i++) {
    30.         numbers[i] = Random.value;
    31.     }
    32.     threadCounter++;
    33. }
    On my dual-CPU G5, this takes 1.74 seconds to run in the editor (averaged over a number of runs, since the times vary a little each run). If I turn one of my CPUs off, it takes 2.81 seconds to run. More modern dual-core chips will probably have a higher differential, since two separate CPUs aren't as efficient as two cores on one CPU, among other things.

    Another important thing to try is replacing these two lines:

    Code (csharp):
    1.         var thread = Thread(RandomFill);
    2.         thread.Start(i);
    with this:

    Code (csharp):
    1.         RandomFill(i);
    That way, threads aren't used at all. When I do that, I get 2.16 seconds with two CPUs, and 2.19 seconds with one. So you can see that in this particular case, it's only a small benefit to run this routine as threads if you have two cores (1.74 with threads vs. 2.16 without), and it's actually worse if you only have one core (2.81 with threads vs. 2.19 without). That's because of the overhead of other stuff (like the Unity editor) that's also running in the background while the threads are running.

    Of course, that's a pretty trivial function, and more involved routines would better lend themselves to threading. Also the results might be better when not running in the editor. (Fractscape uses threads for some of the calculations and gets about a 30% speedup for a couple of things compared to not using threads on my G5. It is however slower on one-core machines because of the threads, but unfortunately, System.Environment.ProcessorCount is broken, so I can't detect when to use threads and when not to. Pretty much everyone who'd use it has at least 2 cores anyway I'm sure...hopefully....)

    Also, keep in mind that sometimes threads are more about running smoother, not necessarily faster. Instead of running a big routine all at once and causing a noticeable hiccup in the gameplay, it can be better to run it in a thread in parallel, so there's no visible hitch. Of course, how feasible that is depends on whether you need the results immediately or not.

    One interesting thing is the number of threads I'm using by default here: I discovered that 16 is the "sweet spot", for some reason, at least on my machine. I get 1.74 seconds with 16, but 1.84 with 8 (and the time gets increasingly higher with fewer), and 1.89 with 32 (and the time gets increasingly higher with more). I would have thought that 2 threads would be ideal on a 2-CPU machine, because of the overhead of running additional threads, but evidently not. Hmm....

    Additional: OK, just tried with my with Mac Mini running a Core2Duo. Actually, the differential when running 2 cores vs. 1 is smaller in this case, not larger. Not what I expected.... Also, 2 threads does indeed get the best performance here, and increasing the number only makes things worse. That is what I expected and wasn't getting from my G5. Just goes to show that you should never make assumptions about anything, eh?

    --Eric
     
  16. Aesadai

    Aesadai

    Joined:
    Jun 10, 2014
    Posts:
    14
    Not to ask a stupid question but are you all talking about multi-core support for the finished game or for the Unity IDE (or whatever we call it)?
     
  17. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    You're replying to a 4.5-year-old thread...it would really be better not to necro-post like this, considering that things change a lot in that time frame.

    --Eric
     
    Aesadai likes this.
Thread Status:
Not open for further replies.