[jamesbondsv]

Say I have the DualProc G4 and OSX. Will OSX allow me to pick certain programs to run on the second proc? Or will it put programs over there when the first proc is getting full? If I am not even close, please explain how it will work.

[MrTomServo]

I have a dual processor 500 with Mac OS X, and this is what I can tell from watching things run while CPU Monitor is running. So, all this information is coming from a graph.

It *appears* that Mac OS X balances the processor load between the two processors. That is, Each processor appears to have roughly the same load at any given point.

As far as I know, you can't assign threads/programs to run on a particular processor. One might be able to do it through the Terminal, but I don't know enough about the BSD terminal to go poking about with my processors.

An interesting -- and somewhat unrelated -- side effect is that SETI@Home will report your CPU time per unit as twice the elapsed time. Of course this makes sense, since I have two processors. But it took me a bit to figure out why (after upgrading from a G3) that data units were still taking 17 hours to process, yet they finish overnight!

[jamesbondsv]

That was really helpful. I wouldn't mind having a duallie.

[MrTomServo]

Oh they're very nice. Aside from Mac OS X, Photoshop runs *super-fine* with the Multiple Processor plug-in. Mmm-mm! I highly recommend it.

[ShortcutToMoncton]

Mmmmmm...duallie......

I was reading IMG's interview with the ATI guy, and he mentions that for some gains there can be up to a 70% speed gain when optimized for duals. That's cool.....

greg

------------------
Though the day's been
really long
I still feel I'm close to
nowhere....

[michaelb]

I was reading IMG's interview with the ATI guy, and he mentions that for some gains there can be up to a 70% speed gain when optimized for duals. That's cool.....

Yes, and Apple's own QuickTime 5 has certain parts optimized for Duals, particularly the areas concerned with the DV codec and image compressors.

To quote from the 'QuickTime 5 PB new features.pdf':

Addition of Multiprocessor Support
Multiprocessor support has been enabled for vector decode (i.e., high quality, low quality, playback and scrub/render). Multiprocessor support has also been enabled for encode in the vector case. For the actual DV operation, the results are nearly two times faster on a two CPU computer than the same code running in non-multiprocessor mode.

Mmmmmm.

[This message has been edited by michaelb (edited 10-24-2000).]

[Scott_H]

I use a 6 proc UNIX box on campus from time to time. It's funny 'cause sometimes when only one thing is running it'll switch which CPU it's on. It'll be chugging along on proc #2 then, blink, it's over on #4.

I think there is a way to lock a process onto a CPU but I bet it depends on what UNIX you are using.

My software developer friends have said that Apple's multiprocessor support is going to much more impressive in the next couple of OS X builds. Right now I have a multi mac and a 500mhz single mac and I don't see much difference. Apparently in the newer builds the finder, Classic, and well designed cocoa apps really fly with the second processor.

I don't remember exactly the scheme used by BSD, but basically what the core system does is this, I guess.

Whenever a new process starts up, it allocates a processor for this process. Although simplified a little, there's nothing more to it.

That is, if you start one program, call it program1, on a single-cpu box and that one program uses the entire cpu, then when you start another cpu-intensive program, call it program2, (or try to do anything else on the machine), then the core system will assign program2 to the single processor (it can't another one as there are no other processors).
Of course, this will cause both program1 and program2 to run slower (as they can only get a maximum of 50% of the cpu-time each) compared to the situation where program1 or program2 runs alone.

Compare this to a dual-cpu system: First, program1 is launched and assigned to cpu1. Then, program2 is launched and assigned to cpu2.
Now both programs can have a 100% cpu-time. The reason you might not see a 100% speed increase as you might expect is mainly due to memory access.
Although the machine has two cpu's, it only has one memory. Every access to the memory goes through the bus, which is shared between the two cpu's. Also, the memory can only handle one request at a time.

So, if both program1 and program2 wants to access the memory all the time, half of the time each of them will be waiting for the memory, although they have plenty of cpu-time. In that extreme case, you will see no speed increase.
I guess this is why you may see no speed difference between a single- and a dual-cpu system.

That gives, that in real world applications, the speed increase will lie between 0% and 100%; a non-memory-intensive program and a memory-intensive program can run together with a big speed increase.


The conclusion is, that only in special cases can a single application benefit from dual cpu's. Photoshop might for example create a new process when applying a cpu-intensive filter, using two processes for the filter; each process might filter half of a picture, utilizing both cpu's 100% for processing the picture. The morale is, that it requires the processes to behave "clever" to get the speed gain.

The OS itself may do something similar, for example running the cpu-intensive Quartz doing all the anti-aliasing, resizing of icons and so on on cpu1 and other parts of the core on cpu2. It might be such optimizations the "bsd friends" are awaiting in future releases of OS X.

Wow! That was a lot of text. Hope it explains a little.

Forgive me for any incorrectnesses in this post; I'm just trying to recall the basics from my Operating System Course in university :-)