Optimise Windows for dual-core

Operating system choices for multi-core
Not all operating system processor time schedulers are created equal. While it is easy – and occasionally correct – to argue that UNIX-like operating systems have superior and/or more efficient processor scheduling methods, our main aim here is to help the Windows-based enthusiasts with their multi-core performance, so we will resist looking into UNIX-like OSes.

NT 5.1 (XP) and NT 5.2 (Win2k3) support multiple physical and virtual processors out of the box. The processor time scheduler in the NT kernel is primarily based on the priorities table discussed earlier in this article. The problem with this, in such heavily-threaded executable environments, is that thread starvation can occur.

Keep in mind that the operating system is the very life of your system. If it doesn’t work well, none of the higher level abstract actions or events – such as those described in the first part of our article – will either. The answer to this cluggy thread and processor time scheduling is to use a more appropriate operating system. How does Vista fix what XP didn’t get right? How does it benefit you in a multi-core world?

All versions of the NT kernel require an interval-timer interrupt routine to execute every ~10ms. The routine looks at what thread it interrupted and updates the thread’s CPU usage stats as if the thread had run for an entire interval – when in reality the thread might have just started just before the intervals end.

The thread may have been assigned to a CPU – or multiple cores! – but didn’t get the chance to run because hardware and software interrupt routines stopped it short of this instead. This can cause unfair CPU allocation. In this model, a thread might get little or no time on the CPU to execute and do any work.

Figure 4 shows how the unfair scheduling can occur when two threads have the same priority and become ready to run concurrently.

Figure 4 – Thread scheduling in Windows XP2K3.

In Vista, the scheduler uses cycle counter registers to track how many CPU cycles a thread executes. By estimating how many cycles the CPU can execute per clock interval, it can more accurately apportion turns on the CPU. The Vista scheduler doesn’t count interrupt execution either. This means that a thread will always get at least its turn on the CPU and never more than an extra clock interval of execution, resulting in greater fairness and more deterministic execution. Figure 5 shows how Vista responds to the scenario shown in figure 6 by giving both threads at least one time slice interval of execution.

Figure 5 – Thread scheduling in Windows Vista Server 2008

The simple answer is to go out and buy Vista for your big new boxen. Is it the economical or rational choice given the operating system’s maturity? Probably not. Be well informed however – it will become a more and more appropriate choice as the underlying applications built for it take better advantage of multi-core environments. XP will no longer be ‘faster’, and it will hamper your performance, in time.

Graphics, sound and gaming in multi-core
So we now have a way to control the threading priority of your executables. We can also tell them what cores to process on. We even have an operating system that treats your threading model with a little more respect than previous efforts. We are still missing some ‘glue’ however. Drivers and APIs.

When you are gaming, you are exercising your system in ways that desktop applications rarely elevate to. CPU utilisation, GPU throughput and SPU decoding are all intensive. Multi-core games are becoming more common, slowly but surely. Supreme Commander, Command & Conquer 3, Crytek’s Crysis and the next iteration of Half-Life 2 are all catering to the QX6800 in ways that haven’t been seen in previous games. The challenge for game developers, is finding ways to parallelise their code to the level that a QX6800 can best make use of. The types of threading that game developers use fall into a few categories:

Single threading – throwing a single thread on the pipeline. The CPU will deal with it and load balance.
Course threading – splitting ‘systems’ between discrete cores. An example might be putting AI on proc0, physics on proc1, GPU offloading on proc2 and networking on proc3.
Fine-grain threading – making many of the same process and splitting them across different cores.
Hybrid threading – a mixture of course and fine grain threading.

Both Valve and Crytek are currently embarking on their implementation of hybrid threading. To get the most from it you need to be running the appropriate ‘glue’. First and foremost, if you’re using an NVIDIA card, the drivers must be current. Since the 96.xx series drivers, NVIDIA has been releasing multi-threaded drivers for its video hardware, as has ATI in the form of its Catalyst driver sets. Similarly, SPUs such as the Creative X-Fi series have highly optimised multi-threaded drivers available for download. Don’t neglect to use the most current driver. Doing so could seriously hamper your performance.

Next, there are a few dark secrets Vista hides, concerning GPU, SPU and processor performance for threading, found here in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figure 6 – Vista registry addition for GPU priority.

Here, with some care, you can change the thread allocation priority for your GPU and SPU. Experiment with the values for GPU priority and do some benchmarking. The results may surprise you!

Going a step further, we can tune system-responsiveness as a function of the trade-off between pushing threads quickly out or letting background tasks process quicker by using the following registry entry:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness

Figure 7 – Vista registry addition for system responsiveness.

Until next time, take your threads seriously!