What is SMP??

Editorial note: I have heavily modified this article, not because it was bad, but
to simplify it for those not familiar with multiprocessing. Blame me for all the analogies. 🙂

The term “SMP” is an acronym for “symmetric multiprocessing”. This is
actually not a hardware but a software term which applies to an operating system
architecture.

“Multiprocessing” is fairly easy to figure out – more than one CPU in the machine.
processor (CPU) within the same machine. Each processor (not
necessarily just two) accesses the same memory and the same peripheral
devices.

But what does “symmetric” mean?

The OS has a number of jobs to do, like deciding when processes get some CPU time, and how
much, managing memory, and running the I/O devices.

An operating system with SMP capabilities treats
each of the multiple CPUs exactly the same. This
means that anything that needs doing can be done by any of the CPUs in the
system.

This is not the only kind of multiprocessing, though. You can also have “asymmetric multiprocessing” (AMP). An AMP system could be designed to
make one CPU the master, and the others slaves. The master is the ringmaster running the whole show, and tells the slaves what to do.

For instance, the master CPU tells a slave “run this process for a few milliseconds or until
you need something like I/O. If the process demands I/O before those
few milliseconds are up, the slave CPU stops running it, reports in to the master, and awaits
further orders. If not, after those few milliseconds, the slave CPU stops
working, and tells the master, “Job done. Now what?”

This can work well where user jobs tend to be long-running and computing-intensive, like
physics research at a university. It would be like a master telling a slave “Plow those eighty acres.”

But if that university computer is mainly used so beginning student programmers can do
their homework, the slave CPUs are spending more time running back and forth to the master than working.
The master spends all his time getting hassled by the slaves, and constantly having to handing them new tiny tasks.

It would be like a master having to give a slave new orders for each plant he harvests. This can leave you with a multiprocessing system that
does LESS work than a single-CPU system.

In a symmetric multiprocessing system, by contrast, each CPU usually figures out
what to do for itself, and each CPU is capable of doing anything that needs
doing. That would be like two farmers seeing what needs to be done on the farm and taking
care of it without having to wait for orders.

For most situations, this leads to better performance over a wider range of workloads.

So why might most people want or use an asymmetric multiprocessing operating system?

There are lots of things an operating system must do that must be performed by only one CPU at a time.
Things like updating data structures inside the operating system or giving instructions to an I/O device.

It’s like a farmer milking a cow, two farmers trying to milk the same cow doesn’t work (and SMP has to take extra steps to
ensure the two farmers don’t fight over milking that cow). The simplest way to solve such problems is to assign all such potentially-
conflicting work items to a single CPU.

For a typical home PC user doing just one major task at a time, an AMP would be quite suitable.
There is normally only a small set of runnable tasks, with a low volume of I/O, so a CPU can
handle the “master” role without trouble.

SMP is just icing on the cake, like having a farmer
having someone else run little errands for him when he’s in the field. Indeed, in most cases, a typical user would probably not notice the difference between
a multiprocessor and a uniprocessor system, except that those infrequent
occasions when the system appears to hesitate for a moment will become even
more infrequent.

Many people with SMP machines really aren’t using SMP. The biggest benefit they get
is simply giving different tasks to different processors. You might, for instance, run SETI@Home or
Folding@Home unimpeded on one CPU while you do all of your
usual work on the other CPU.

Let’s take our farmers. If the field has to be plowed now, and Bessie the cow has to be milked now, you’re a lot better off having one farmer milk the cow and the
other plow the field rather than have one guy bring the cow out to the field and try to plow and milk at the same time.

On the other hand, if all the second guy has to do is carry a jug and pour the guy plowing a drink once in a while, the second guy is mostly a waste.

True SMP involves multiple processors handling one general task. Like many farmers plowing a big field. Applications can be coded to make use of multiple
CPUs. If the application is “multi-threaded”, that means it has divided up its work into a number of subtasks, each of which can be completed separately at the same time.

If the operating system supports threads, the threads within
a single application are treated as separate tasks, so
the threads can execute on multiple CPUs simultaneously.

It’s easy to see how this can help a task like image-processing. If you decide to turn
the blue in a picture to green, the program doesn’t have to wait for the blue pixels in the top left-hand corner
to turn green to figure out how to turn the blue pixels green in the bottom right-hand corner.
The program already knows what it has to do, so it can split up the picture into areas,
and each processor works on its area.

It’s like plowing a field. You don’t have to plow one part first to plow the rest, so two guys plowing half the field each will get the
job done faster than one guy plowing the whole field.

Even without threads, an application could be written to divide the task up into
smaller tasks, which can then be run at the same time by different processors.
This basically does the same thing as threads.

Whether SMP works well with a task or not depends largely on whether you can split
up the task like you could with plowing. If you can, it works very well.
If you can’t, it doesn’t.

If you first have to buy two plows before you start plowing, the second guy can’t plow until the first guy comes back with
the plows, and sending two guys to buy the plows isn’t going to make buying any faster.

So, on the desktop, is SMP important? That depends on what the job is, and how efficiently you
can split up the task for your farmers. If you’re basically doing one big thing at a time that’s not
computationally intensive and can’t easily be split up into smaller tasks, probably not – AMP or uniprocessing would likely serve
just as well.

Is MP (multiprocessing) important? Again, it depends on what you’re doing. If you can give that second
farmer something else important to do, it can be, if not, then it isn’t.

But when the necessary applications do lots of computation, and are coded to take
advantage of multiprocessing, big gains are possible. Systems with dozens,
hundreds, or even thousands of processors are built precisely to take
advantage of those gains, just like many, many farmers bring in a bigger harvest than just one, no
matter how fast he is.

Email Terry