Reply 60 of 279, by Scali
wrote:I'm not a game programmer, so I'm not really aware of how guys like Tim Sweeney are evolving their approach with increasingly parallel hardware, but I am familiar with numerical programming on dozens or hundreds of cores. In general I can say that parallel programming is not straightforward or cheap and any opportunity to use knowledge of the target platform to simplify the task of adapting software to a multi core environment will be embraced by developers, especially if doing so (assuming small core counts) has little no downside in the economic lifetime of your product.
The most versatile approach to multiprocess computing is to partition the problem in a fine grained fashion amongst your processors, but this is very expensive in terms of engineering. Instead, if your network code, audio code, or some other subsystem does not lend itself to parallelism, you don't achieve worthwhile gains by partitioning, or it's not worth the cost in developer time, it can be spun off on a thread in coarse fashion for the scheduler to load balance. On a processor with a few cores, large elements such as graphics remain unitary within their respective threads, but have a core fully dedicated to their execution. Housekeeping threads and the OS share what's left.
This is useful for small core counts as it allows the resources available to be utilized while avoiding the significant cost of completely re-engineering the game engine potentially down to it's inner loops. The approach runs out of steam with large core counts due to the limited number of application elements to be spun off and the significant difference in compute time required for the different threads (compare network code vs scene setup and render).
Well, my point is that all the 'low hanging fruit' of splitting up tasks in multiple threads at a coarse level has been done about a decade ago. Since then they have been working on optimizing the computationally intensive tasks such as physics with parallelism.
Don't forget, the most parallel task in a game is the rendering (known as an 'embarrassingly parallel' problem), and that was already tackled with specially optimized hardware before multi-core CPUs were even available in the mainstream.
People tend to talk like there's a lot of performance still on the table, and if those lazy developers would just start writing multithreaded code, you know, that silver bullet, we'd get incredible performance boosts. It's nothing like that.