[citation][nom]antilycus[/nom]use a kernel that has the best thread management available (Linux). That will solve your CPU problems. I run clients windows server 2008 on a VM using Debian/Linux kernel and the performance differences is unbelievable. Thread management on WIndows kernels is a joke (xbox 360). PS3(though i cant stand it) had the right Idea by using Linux, it was their CELL that was problem (memory bottleneck and registers bottleneck due to 1 "core" managing all cores).I don't know teh O/S or Kernel used in Wii U, but if 3 processors can't get it done, your developers are stuck in 1999. They (like most programmers) need to understand writting threads, not objects.The CPU count is plenty high, the complete lack of understanding HOW to write threaded games, is the problem.[/citation]
Two things:
Not all tasks can be given their own thread. It doesn't work like that.
The number of cores has nothing to do with the computational power of the CPU. I can have an octocore CPU, with each core being very weak, or a dual core with each core being very powerful. So saying because it has three cores means it's powerful enough for task X is completely conjecture.
In the article, he is talking about issues with multiple entities on screen. To make this multithreaded, you would have to give each entity its own thread. That would be fine if each entity didn't need to interact with others, but I assume that if (example) soldier1 is at coordinate [3, 6] moving to [3, 3] and soldier2 is at coordinate [3, 5] also moving to [3, 3], they need to know that they can't occupy the same space. If they're both on different threads, there's no way to ensure that they can both access eachother's data (their location) and have it be the 'correct' data for any point in time since there is no way to ensure that the threads are computed at the same speed.
There are also issues with access locks, overhead from making copies of objects (A reference passed into a thread that is accessed from other threads before or after must either be immutable or have its values coped on passing in and copied out on return. But if multiple threads copy it and change it, whose data is the right data to copy out when they are finished, since there's no way to know which one will finish first?)
Now imagine 30 soldiers, each with their own thread that determines their pathing. For soldier1 to know that he can move to coordinate [x, x] he needs to know that nobody else already is.
His pathing thread must look at all the other soldiers' values (which means they can't be locked, which in turn means their threads can't be running), lock its own values, compute his path, then unlock his values.
Each soldier's pathing thread would need to do the same. If they can't access each other while they are running, that means each thread must take its turn to completely finish before the next can, one at a time. This means you've completely lost the advantage provided by multiple threads.
Point: Sorry for the short novel's worth of text. For something to be given its own thread, its data must be completely isolated from the rest of the code, and any code depending upon it to return some data before it can continue will lock up until the thread completes (the elapsed time until completion being unknowable).
Facebook
Twitter
Instagram