Dual Processors?

[Mincer]

For PC Recording, I see very little mention of using dual processors- some companies that make made-to-order DAWs use them, but not many. Is there an advantage to using a dual processor machine, or is that money better spent elsewhere?

[simon784]

A Dual Procesor computer is like an "Animal Traction Car" with 2 horses.
The force is divided in both of them instead of one. That makes their work lighter.

But if there is essencial stuff that you still don´t have, you may want to buy that first.

[DAS]

An important aspect to consider is whether the software you use can actually take advantage of dual processors. Upon investigating you may find that much of it does not (yet), which mitigates the benefit of them quite a bit.

[TeeCee]

A Dual Processor PC is more like 4 hands and two brains than an "animal traction car" with two horses. The load is not automatically lightened just because you have two processors. If you are typing, for instance, using a standard typing technique, one brain and two hands will work and one brain and two hands will wait. But if you are also filing while you are typing, the other brain and two hands can perhaps be filing.

Going from a 500MHz PIII to a 1GHz PIII is much more like adding a second horse.

[NukleoN]

I have a dual processor system because of the 3D programs I use, but my sequencer (Sonar 2) is actually written to make use of both processors. I am not exactly sure how it is multi-threaded, but I imagine that Sonar will make use of both processors when you're editing or processing audio or MIDI with FX and such.

[jwofford]

I'm going to get a bit technical here, but I hope it is clear enough to shed some light on how multi-processor machines actually work. I know I'll be giving a bit more info than is actually needed, but sometimes that can help you feel a little more confident about your choice.

The first thing to note is that the architecture and operating system are absolutely crucial. For instance, Mac OS X has been tailored to the nth degree to be multithreaded (more on that term in a bit), whereas Windows 9x/Me does not even include support for multiple processors (it will generally run, but the second processor is basically ignored).

<b>Multithreading</b>
The concept of multithreading is actually a fairly simple one. It's something we do all the time and never even think about. Unfortunately, it's a relatively new concept to most popular operating systems (though UNIX, VMS, and a few others have been doing it for years). The idea is this: we take jobs that are not dependent on each other in realtime and split them up into seperate tasks. Seems easy right? If you're cleaning the house and you need to wash windows and vacuum floors the tasks are unrelated. Therefore we can treat them as seperate entities. We can call these entities 'threads.' It stands to reason then, that a 'multithreaded' program is one that splits up it's tasks into logical entities. A practical example of this in a DAW is the processes of handling incoming audio, playing audio, and we could even add another process of, say, rendering the user interface. Obviously, though they may share some information back and forth, these tasks don't directly depend on each other.

<b>How it works, the low level</b>
Every time your computer executes a bit of code it is sending certain binary signals to your CPU. In a traditional program this is simply a constant string of commands that are executed as they are reached in the program. The problem with this is that sometimes we find, for instance, processes that need to be run in pure realtime are being slowed down by processes of lesser importance that could wait. Another scenario is any bit of code that needs to be doing several instances of the same thing at the same time (such as software for a webserver listening for different connections). If there is a method to treat these relatively unrelated jobs seperately we can increase effeciency. Let's look at a very simplified version of what our DAW example above might look like in standard single-threaded style coming into the CPU:

CPU: Listen for incoming audio -> Play outbound audio -> Draw GUI -> repeat indefinitely

Now, by defining in our program that these tasks can be handled differently all we have to do is specify them as different threads. The benefits of a multi-processor machine become instantly evident. Say, for instance, that we have two processors on board. In a very simplistic manner this allows us to seperate our threads and execute them at the same time. This may look something like:

CPU1: Listen for incoming audio -> repeat
CPU2: Play outbound audio -> Draw GUI -> repeat

This allows us to maintain excellent recording integrity by, in essense, giving the recording process itself a computer of its own.

<b>Thread scheduling</b>
Up untill now we have talked solely about the program as if it were running without an OS (operating system), therefore I've not yet told the whole story of threading. After all, it is the operating system that decides how and when the treads are going to execute. This is known as thread 'scheduling.' The type of scheduling the operating system uses will determine how rubust and effecient (often mutually exclusive) the whole system will operate. There are a whole meriad of ways that have been dreamed up to get the best efficeincy out of your threads.

It should be noted that threads can actually be paused, let another thread execute, and then resume when it's done (or paused). This can come in handy when the OS decides something is more important or would be more effeceintly executed before the existing thread has completed. This is all determined by the Operating System scheduler in a vast number of ways (which I won't cover... and frankly would have to do a lot of reasearch to really know).

<b>Thread Priority</b>
So looking back at our DAW example, we have one problem. Our program is very GUI intensive, and therefore we're getting audio playback lag because the playback thread has to wait on the GUI rendering thread to finish between each execution. This is simply unacceptable. The answer to this is setting a 'priority' on the thread. This is, by default, set by the OS scheduler to whatever it deems necessary, but can be overriden by the program itself. So here we tell our program that recording and playing audio is much more important than rendering the GUI. With this we might get something along these lines.

CPU1: Listen for incoming audio -> repeate
CPU2: Play outbound audio -> Play outbound audio -> Render GUI -> Play outbound audio -> repeate

The GUI rendering could even be (and most likely would be) paused mid thread to let audio playing occur when needed. This is, of course, all done at insanely fast speed so that everything seems to be running at the same time.

<b>Multithreading and Single CPU Machines</b>
So... all of this is pointless if I have a single CPU machine right? Not really, no. Granted, the extra CPU helps emencely, but the scheduling of processes will also speed up a single CPU by generally making it more effecient. Now, using our scheduling and priorities, the OS will know to first take care of all of our important audio transactions, and then, when it has a few spare cycles, render the GUI with them. In many ways this can make a single CPU system act like it has more than one CPU because it all happens so quickly. A single CPU system could feasably switch between threads a couple of hundred times each second.

<b>Summing it up: the fact and the myth</b>
So, to answer the question asked about the necessity of multi-processors... well, it isn't entirely black and white. Does a second CPU double your performance? No, not necessarily. Does it improve it? Only if *BOTH* the CPU and the application are multi-threaded. This is something you'll simply have to check with the venders of your software. Off the cuff I can say as far as OS's go, Windows 3.1x/9x/ME are *not* multithreaded; Windows NT/2k/XP are all multithreaded, but are somewhat famed for their ineffeceint scheduling; as almost all UNICES have been multithreaded for years, I'm going to have to assume that OS X is, as it was based off of the BSD UNIX kernel that is famed for it's good scheduling; Mac OS <=9.x... you'll have to check that for yourself, my guess is that it has at least some threading functionality. Also, do not despair that you're wasting all of your multi-threading if you go single CPU. As I illustrated above, it's still effective in a lot of ways.

As a personal recommendation, I would have to say that unless you are planning on doing some very serious intensive audio work with >52 channels and lots of plugins and/or virtual instruments, you're safe (and richer) with a single CPU. If you're going for the massive projects, go for a Dual G4 with OS X (assuming you can get your software for it). Next to that is a Dual AthlonMP or P4 on XP Pro.

<b>Final notes and limitations</b>
1. You generally want about double the RAM you would use with a single CPU on a dual CPU machine. Each CPU will want it's own memory area to work with. If you don't upgrade RAM when you go to two CPU's you're likely to see much less performance increase.
2. Don't fall into the, well... if I have two 2Ghz machines it's like I've got a 4Ghz machine! myth.
3. Unrelated, but most games aren't multithreaded (with a few exceptions) so don't use game performance for an extra excuse for dual processors.
4. Be sensable. Plenty of people do very well on a single processor. You're likely to do better spending the money on more RAM... or perhaps even a dual-headed display (it can be quite nice to have your tracking window on one monitor and virtual mixing console on the other for instance).
5. Make sure *everything* supports the extra processor before you drop the $$$ for it.
6. In all the technical mumbo-jumbo... don't forget you're trying to make music (I assume), not show off your PC overkill or play with toys you don't need. Who knows how many times I've foregone doing a project to play with a toy I've never actually used in a practical sense. When it comes down to it, it's all about productivity.

I hope this helps some one. If you have any questions or comments, I'll check this thread. Flames can be respectfully forwarded to /dev/null ;)

-John

[jwofford]

So, apparently I had HTML code OFF... just mentally replace the little <b> </b> tags with some nice bold on those topics ;)

[NukleoN]

The first thing to note is that the architecture and operating system are absolutely crucial. For instance, Mac OS X has been tailored to the nth degree to be multithreaded (more on that term in a bit), whereas Windows 9x/Me does not even include support for multiple processors (it will generally run, but the second processor is basically ignored).

LOL! It's hilarious that you're comparing OSX to Win 9X and ME. It'd be more fitting to compare Apple's new multi-threading OS to Win2K or XP, both of which are multi-threaded. Multithreading on the PC has been supported since the days of NT.

Anyway, it was a glaring omission and I wanted to address it.

[jwofford]

I was contrasting, not comparing. It's quite different. I was simply pointing out that some OS's (complete with example) don't support SMP and some do. I really don't see why you have a problem with this. As for being an omission, if you'd read this in its entirety (or retained any of what you read if you did) you would have noticed that XP/2k/NT are discussed... even in comparison to OS X.

It would seem to me that you are, for whatever reason, simply searching for something to nitpick about. I find this annoying at best. Why not go for the spelling errors? There are plenty. Have at it.

[NukleoN]

The first thing to note is that the architecture and operating system are absolutely crucial. For instance, Mac OS X has been tailored to the nth degree to be multithreaded (more on that term in a bit), whereas Windows 9x/Me does not even include support for multiple processors (it will generally run, but the second processor is basically ignored).

You're comparing Apple's multithreaded OSX with non-multithreading OSes from Microsoft. It would have been less misleading to simply compare WinXP to WinME, or perhaps OSX to every other OS we've seen from Apple.