Multi-Core Computing

Have you noticed how fast new computer hardware has been getting? Working with multiple operating systems is part of my job, so I get an amazing sense of how different hardware and software stack up and how they’ve changed over time. It’s neat to see how much your perspective changes over time as well. My favorite desktop from a few years ago seemed very sleek at the time, but today it just seems plain. If you’re a history buff (and I tend to be), you can imagine how today’s systems might have run on a Intel 386SX system or something even earlier. So, what’s changed to make those advances? Computer designs have changed, cooling technologies have changed, and, very recently, we’ve seen the mainstream adoption of multiple processors running in a single system. We call them multi-core processors. The wide-spread adoption of multi-core processors on the desktop has made computer system programming vastly more complicated for the computer system designer. The tipping point of that mainstream adoption forms a junction, and programs today have to be written very differently, or they might require very specific handling so that they run correctly.

A multi-core computer is a computer with two or more processors that share a lot of technology between them. They often share a single system bus interface, and they often share a single interface to main system memory. Since they can share that interface to main memory, they can also share a very fast L2 memory cache between themselves as well. As you might suppose, there are many variations, and endless discussions on those variations. In the end, the basic facts remain – even with that much shared hardware, the operating system still has more than one worker on the job – that’s the beauty and the curse.

The beauty is easy to see, and the curse is easy to experience. With multiple independent processes running beautifully organized memory, your multiple CPUs can each buzz right through at maximum speed. That’s the beauty. The curse is that memory is rarely perfectly organized, processes often try to talk to one another, and, even worse, they try to talk to peripheral devices. This requires coordination and waiting – those things that keep the operating system very busy and the user wondering. It can get so bad that it seems like there is only one processor there, and it’s having a bad day. In the absolute worst cases, a large program is run on a system that it never was designed to run on, and different parts of the program start stomping on each other’s shared resources. This result is very interesting if you are a software tester. Since that’s just what I do, I’ve seen firsthand how hard the job that multi-core processors put on operating systems and the programs that they run.

Operating systems schedule programs to run on a computer. On single core computers, the decision is fairly straightforward – the operating system schedules programs to run one after another or there’s some sort of simulated multi-tasking. In the end, there are very well-defined points where the operating system has complete control over the whole computer. The situation in a multi-core computer is more complicated, and some surprising problems can develop. It’s that element of surprise that’s the real problem, since the complications can be programmed away. How do you deal with a program that just refuses to work or schedule right on a multi-core computer? The answer is often just a few mouse clicks away.

That answer is processor affinity. Every operating system gives you, the user, and the programmer tools to reach in and nail that process down to a single core or group of cores. For the user or system administrator, the tools that set the process affinity come in two forms – programs that patch the executable, and programs that set the process settings for running processes. The Windows Application Programmer Interface (API) and other cross-platform APIs let programmers tell the system how the program can be best run.
In Windows, the user’s first tool is just a right-click away in Task Manager. Open Task Manager, maybe with a handy Ctrl-Shift-Esc, find your application (you can type the first few letters of the application name to get you there,) and select “Go To Process”. Right-click on the process, and select “Set Affinity…”. Remove the check-marks for all but one processor in the list, and you have tied the program to that one core.

That’s very convenient the first time you use it. On Windows XP and Vista, that setting does not persist after the program shuts down the first time. Since that setting is so volatile, here are two ways to start a program with the affinity set. Put either of these command in a batch file, run that batch file instead of the original program, and you’re set. First, there’s the START command. It’s native to Windows, and with Windows 2003 and above, it has an /AFFINITY argument to set which processor(s) the program runs on. The other start-like command is Microsoft Sysinternals’ very convenient psexec.exe utility. It has an “-a” option that takes a comma separated list of the core (processor) numbers to which to tie the program.

There are other methods that are less flexible. On the Windows 2000 Server Resource Kit Supplement One, there’s imagecfg.exe. It is a patch utility that adds settings to an executable so that it only tries to run on the specified processor cores. Imagecfg’s ‘-a’ argument takes an affinity mask bit field parameter that indicate which processor cores you are letting the process runs on. Various game patchers have taken this same approach. Since they are changing (optimizing) specific executables for specific functions, they have a high degree of success. The trouble with this, of course, comes if you are trying to run a “signed” executable – that’s strictly impossible if you are patching the executable!

So, with today’s innovative tools, that’s all there is to fixing this multi-core problem. There are very good programs out there that have very interesting problems running on multi-core systems. There are also well tested, portable, and highly configurable fixes for this situation. Now that you know about a few of them, why not try them out? Who knows? You might just re-discover how fun one of those old games was back in the day.

If you have questions about multi-core processors, post it in our forum to get expert advice from industry leaders. I’ve provided a few links to my top multi-core sites:

TechNet Blog – Really nice overview of these options, but the affinity mask selection is incorrect

Windows API – SetProcessAffinityMask Function

Open-source Cross-Platform API that provides functions for binding to a CPU or CPU groups

START /affinity – blog comments contain the correct affinity mask selection

PsExec

Affinity mask in imagecfg

Deus Exe game patcher for modern systems

Windows Server 2003 Resource Kit tools with a different sort of affinity setting tool

Tom’s Hardware Guide created an XP-only tool for setting Process affinity

A site with an available download of the Tom’s Hardware Guide tool

Post a Comment

Your email is never shared. Required fields are marked *

*
*

Proudly Made in the USA
© Copyright 1996 - 2017, Sealevel Systems, Inc. All rights reserved.