Unravelling threads


 
Multicore CPUs are here to stay. It’s hard to buy a computer these days that doesn’t have multiple cores. The system I’ve been dealing with most often (Xbox 360) has 3 CPU cores. My desktop Windows machine has 4 cores. Even my laptop is a dual-core machine.
 
The challenge for developers is utilizing that processing power effectively. One advantage to programming a console like Xbox 360 is that you’re always guaranteed to have 3 cores, each with two hardware threads. That means you can write your game to have six threads and know that those threads will always be running independently. PC game programmers have a larger challenge, because they can’t rely on having multiple cores. Even if they do detect multiple cores (see the CoreDetection sample in the most recent Dec 2006 release of the DirectX SDK), not all CPU cores are created equal. From a performance standpoint, the difference between a hardware hyperthread and an independent CPU can be drastic.
 
No matter what platform your game is running on, it’s likely that you’re considering using multiple threads. That’s good. The important thing is not to go overboard when it comes to threading. I’ve talked with developers that want to have dozens of active simultaneous threads. That can make a lot of sense on paper, but when it comes to real-world performance, a massively threaded architecture is almost certainly a mistake.
 
The other key point about game multithreading is reducing your synchronization points. Thread synchronization will be a significant bottleneck if you do it too often. What’s too often? More than a few times per frame. We generally suggest your ultimate goal should be to synchronize once per frame. Perhaps unobtainable, but a goal worth striving for. This guideline leads to systems that are generally multi-threaded at the feature level. For instance, many Xbox 360 games have a primary game thread, a graphics thread (submits commands to the GPU), an audio thread, and perhaps a decompression or file I/O thread. Depending on the title, it’s not unusual to have game-specific threads for performing compute-intensive tasks like physics simulations (e.g. cloth), particle effects or lighting effects.
 
For PC games, the best way to think about threads is in the context of "how can I use any additional processing power to make the game look (or sound) better." On a single-core machine, your clouds may be pre-rendered and particle effects might be limited. On a dual-core machine, your clouds might be procedurally generated and particle effects could be much more visually appealling. They key is using that additional processing power not to add gameplay elements, but to enhance the experience for those customers who have better hardware.
 
Advertisements
This entry was posted in Game Programming. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s