Quote:
Originally Posted by
DuckieHo 
Not always though.
Some workloads are easily multi-threadable... lightly/no interdependent threads with relatively low memory footprints. This would be like brute-force, video editing, financial models, nuclear modelling, etc. These are trivial implementation cases as many of this applications are already multi-threads since there is the performance demand and financial incentives in increase performance.
Some workloads are not easily multi-threadable with dependent threads. See Amdahl's law:
http://en.wikipedia.org/wiki/Amdahl's_law
Also, large applications can become very complex to develop.
It's true that some tasks are difficult to split into multiple threads, but the vast majority of software isn't anywhere close to that. Take the main loop of a game engine, RTS for example, I see no reason I/O, rendering, pathfinding, unit creation, collision, AI, physics, and unit removal can't run simultaneously, Most of them may have to complete their tasks every iteration, but you can start them all from the state of the previous loop, and update the master game state in a deterministic manner after starting all the tasks. You're still limited by whichever task takes longest, but you know where to optimize. The best reason not to do this is that the target hardware is fast enough to run it all in one or two cores at acceptable framerates, and you're usually limited by GPU.
Edited by TranquilTempest - 7/5/12 at 10:36am