Hello Scott,
The recommended approach for data parallel optimization on Win8 is to use the WinRT ThreadPool::RunAsync API as opposed to trying to build your own parallel work queue implementation from scratch. ThreadPool is a core part of the OS and is aggressively
optimized (we use it ourselves in some of the most important and performance sensitive parts of the system). It is absolutely possible (in fact much easier than with the legacy Win23 threading APIs) to achieve awesome data parallel performance this way.
Couple of important things to bear in mind about getting good performance from ThreadPool:
- Use it as-designed as a work pool primitive; don't try to layer some other work mangement system on top of it. You shouldn't be trying to manually schedule work across cores: that's the job of the OS.
- Be sensible about how many buckets you split your workload into. You typically want to be looking at double digit threadpool tasks per frame. Too few, and the OS doesnt have enough opportunities for meaningful parallelism. Too many, and
you'll find yourself drowning in work submission and coordination overheads.
Note that there are good reasons for the OS wanting to control work scheduling as opposed to letting every app roll their own. Raw perf is of course important (and ThreadPool can deliver this), but in these days of laptops and tablet devices,
power usage and scalability across different hardware are also crucial parts of a good user experience.
A problem we see a lot with legacy games that manually divide their work over all available cores and set explicit thread affinities is, what happens when this content is run on the latest and greatest hardware that has 8 cores and better performance than
the developer ever expected? Ideally this newer machine should be able to run the game on a single core without even breaking a sweat, but because the developer told the OS not to do that, instead every core must be woken up every frame. They might
only run for a couple of milliseconds and then sleep the remaining 14, but this prevents any core from ever going into full power collapse, which destroys battery life.
Using ThreadPool, you just submit a bunch of work and let the OS decide where to run it. If all cores are neccessary to achieve your performance goals, that's how it runs. If just a couple of cores are fast enough to keep up, the others can be
powered down. If the user decides to dock a video chat app alongside your game (remember all Metro apps can be docked next to others, so you can't count on always being in exclusive fullscreen mode!) the OS might need to run your game logic on N-1 cores
to free some cycles for that other app.
A static processor query API cannot help to solve this sort of dynamic scheduling problem. This is something only the OS knows enough to do right, which is why Metro ThreadPool was designed the way it is.
Hope that explanation makes more sense of what you are seeing, and will help you understand how best to move your threaded code over to this new platform.
