koobas.hobune.stream
Optimize for multicore systems
Hi,
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.
Any advice would be appreciated.
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?
The idea not to let the enemies update every frame is great. I will try to implement this.
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.
The problem is, that I don't need threads. The AI script is very simple and controls the movement as well. Thus I need the Unity functions. Why aren't many scripts useful for multithreading ? I've got about 50 - 500 enemies and each has its own script. One should think that each core could handle 100 enemies and everything would be fine.
As I mentioned, Unity functions can't be multithreaded. It doesn't matter how many scripts you have: they all run as a single thread, in linear order. Potentially you can offload AI calculations in separate threads, as long as anything that touches Unity-specific functions runs in the main thread.
@lhk, you're welcome to try finding engines that are significantly more multi-core usable for scripting. Game program$$anonymous$$g typically does not lend itself to such a thing.
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.
Great Software! Thanks!
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.
