I'm using a computer with an AMD 6 core CPU. When I spawn a huge amount of enemies the framerate drops till the game is unplayable. However using Core Temp I can see that only 1 core is stressed. The other cores are at about 5% load. So here come my questions:
Does Unity support multicore systems
?
If it does, how can I use more than
one core ?
I already thought about using more than one thread in my script. The only problem is, that I don't need more than one thread.
Do you need more than one thread ?
Are there game architectures that support Unity with its "internal" multithreading ? I guess that many small scripts may be superior to one big script.
Many small scripts won't run any differently than one big script as far as CPU usage goes. In order to use threads, you need to explicitly use System.Threading in your scripts. Note that no Unity functions are thread-safe; only Mono functions can be used in such a way. (Unity 2.6 will randomly crash if you attempt otherwise; Unity 3 simply won't run attempts at threaded Unity functions, though it doesn't give you any error messages.) The Unity engine itself has a certain amount of multi-threading, such as physics and mesh skinning.
As Eric already said you'd have to use System.Threading yourself, but you can't call Unity functions from a separate thread. However if you are experiencing frame drops those might be caused by graphics rather than your own scripts. If you have unity pro you can check the profiler to see what's causing your framerate to drop. If you don't have pro you could still take a look at the Stats in the game view. If you are using lots of draw calls your fps drop is probably caused by rendering rather than your scripts. If that's the case you should think about how you could optimise render performance.
If scripts are causing the problem you should think about how to optimise those scripts. Debug.Log will slow down everything for example. If your code is already optimized you could also think about how often your enemies need to update. Maybe you are still fine when those enemies only update every other frame?
Having been an engine programmer and a game designer, I'd love to have some way of parallelizing parts of my game.
While I agree that general game logic is difficulty to parallelize, I wouldn't mind some options without having to go all the way to building my own job system. Given your company's awesome cross-compiling expertise, I would think there'd be some people already experimenting with this.
For example:
i) Some built-in parallel options :
Deferred ray casts (These would be
available next frame so they could be
batched and parallelized)
Deferred API physics calls
Etc
ii) or a even better, a more general deferred batching system
example: foreach (input, output, function, when)
if we were able to tag functions with
no side effects, you could even cross
compile to SSE or the like.
The ability to parallelise scripts is certainly something that we would not only benefit from hugely, but also, something that we would be losing out on severely if we do not have it.
It's not just about multi-threading and assigning jobs to new threads etc. What about having single tasks that you want spread over multiple cores so that they all share the load and not just one is stressed ? Multithreading and parallelising are both important I would say.
Multi core cpus are a reality here and now and we lose performance not using them to their fullest.
Another thing would be to allow control over the degree of parallelism so that tasks can be told "use as many cores as you can but no more than 2 or 4 for instance".
Especially graphic intensive scripts would see massive performance boosts if they could spread the load and have more instructions executed in parallel.