Introduction
When a computer has multiple processors, or at least one multi-core processor, there is great potential to increase the performance of your applications, which can be done many ways. In previous articles I have written about multi-threading applications to take advantage of multiple cores. In this article I will discuss what you can do to take advantage of multiple cores while using applications that are single threaded.
Processor affinity is the ability to direct a specific task, or process, to use a specified core. Why is this useful? Well, if a process runs frequently there may be remnants of previous runs of that process remaining in the cache of a given processor. So, if the process is directed to always use the same core it is possible that the process will run more efficiently because of the cache re-use. Another way to use processor affinity would be to direct only one or two performance critical processes to one core while all other processes are directed to other cores. This should ensure that when the performance critical processes require a core one will be available.
Setting Processor Affinity in Vista
In Windows Vista you can set processor affinity by opening the task manager.
Figure 1: Windows task manager.
Select a process listed in the Process tab. Right clicking this process will provide you the menu shown in figure 2. By selecting the Set Affinity menu item the option dialog shown in figure 3 appears.
Figure 2: Right-click menu.
Figure 3: Processor affinity options dialog.
In the processor affinity option dialog, each core available to the system is shown. By checking the box beside a core the operating system, in this case Windows Vista, you will assign this process to that core each time it is run. By checking more than one core, the operating system will attempt to balance the load between the specified cores.
Specialized cores
The case shown above is a typical case and is quite simple. In the near future, setting processor affinity will become much more complicated. Why? Because there is no reason for the processing cores to be identical. When systems start shipping with many dozen cores it is likely that many of these cores will be optimized for certain types of operation. This will be done in much the same way as how a graphical processing unit (GPU) is optimized to perform operations common to graphics processing.
So I am sure you can imagine that when there are dozens of cores, where most are optimized for specific operations it will be quite a complex task to assign the processor affinity intelligently. I believe that future versions of operating systems should take care of this while still allowing user modifications.
It could happen similar to how I describe below.
First, when the operating system is installed, or when new hardware is added, the operating system will identify each core available. This would be similar to what it does now except that it would also compare each core to a previously created registry.
This registry, which I will call the core optimization registry, would be kept by the operating system company and be available for updates. This list would match each core to the operations for which it is optimized. Processor manufacturers would register their cores with this list or there could be some sort of independent review of the processor’s optimizations to ensure a suitable level of optimization (this is probably the preferred method) in order to properly place the cores.
The concept of the core optimization registry could even provide another arena for competition amongst operating systems; whereas different operating systems will likely have different core optimization registries possibly even at various degrees of detail. For instance, one operating system may rank a given core at being optimized for graphic operations, while another operating system with a more comprehensive core optimization registry may rank at the same core at being optimized to 3d graphic operations
Secondly, after the operating system knows of all cores available and has checked them against the core optimization registry, the operating system needs to assign each process to one or more cores based on the types of operations required of the process. During installation of the operating system the operating system could match all pre-installed software to one or more cores as well as matching all operating system processes to one or more cores. Matching these processes to the available cores will be a difficult task.
How would the operating system know what types of operations are required by the processes in a given piece of software? This is a requirement to be able to intelligently assign processor affinity. There could be a software operations registry, where software is registered to the registry along with the types of operations required of the software. But, I am not convinced this is a good idea. Software has such a fast pace of development that I doubt this kind of registry could be made practical. A better idea, in my opinion, is to provide programmatic access to the core optimization registry so that software can be written to set its own affinity. This is probably best used by software installers who will set the affinity (after user confirmation) during installation of the software.
Thirdly, there would still need to be a way for a user to change the processor affinity. This should be done in a straight forward way similar to the method of setting processor affinity in Windows Vista as I described above. Obviously if there are dozens of cores available the layout of how this information is displayed would need to be different, but whatever method is decided upon it should be simple and straight forward. This could be one way for users to personalize the operation of their own computer. Perhaps some clever users will disagree with the affinity chosen by the operating system, due perhaps to a poor core optimization registry, and these users should be able to change the affinity to match their desires.
This is all well and good, but many applications will require differently optimized cores throughout the running of the software based on input from the user or from other software applications. This brings me to my fourth point. (Well, actually it is not really a point at all; I am merely defending my ideas against any readers which may feel I have neglected this common case). A piece of software should have access to the core optimization registry, as I explained in my second point, this not only allows the software to set its affinity during start-up it also allows the software to set affinity for various processes and to change the affinity at any time. Likewise, if an installer sets the affinity for the software application there is nothing stopping the installer from many affinities for the various kinds of processes possible in the software.
Conclusion
The method I described above for setting processor affinity in systems with many cores some of which are optimized for different processes is only one way to accomplish this. Another method I’ve read about, and disagree with, is where the operating system monitors the activities of a software application and how it is utilizing the cores and then assign the process to the core it feels is proper for that type of process. I believe this is the right way to accomplish load balancing. However if this monitoring is tasked with determining the mathematical nature of the process, I believe that the time and processing power required to do this would be a waste. The method I described above allows a software developer to shift this determination to the installation process instead of at run-time. I believe this will lead to a better, more user friendly, end result.
