[rescue] OS X and dual CPU machines?

r.stricklin bear at typewritten.org
Sun Jun 8 23:51:42 CDT 2003


On Sunday, June 8, 2003, at 09:30  PM, N.Miller wrote:

> I can't honestly tell you if the BSD sub-system is set up to take 
> advantage of the multi-cpu facility or not, but I would expect so 
> (seems kind of dumb if it isn't, but hell, that isn't beyond Apple).

My admittedly simplistic test suggest that the kernel isn't as down 
with SMP as it could be.

The fhlushstone (the time to dd a gigabyte from /dev/zero to /dev/null 
in 1024-byte blocks) benchmark illustrates it pretty clearly. Times are 
for my 1.25 GHz dual G4.

Single thread: 4.23 seconds.
Two threads:  18.915 seconds.

Clearly something suboptimal is happening. Contrast that to Tru64 v5.0A 
which shows some level of threading even within the kernel... a dual 
processor machine will run the single thread benchmark faster than a 
single processor machine, which isn't a trait I've noticed on too many 
other systems.

There's a big table of results out of my lab up on the web, in case 
you're curious how those results stack up to other systems. If you're 
shrewd you can learn some interesting things. Not bad for a purposely 
frivolous benchmark.

http://www.typewritten.org/Articles/fhlushstones.html

> Ugly, huh?  Netscape (7.02) has 118MB footprint with one window open.  
> Terminal takes up 113MB or so with the default scroll back of 10K 
> lines. :-p

Except it's not using that much of your memory. It's mapped in all of 
the backing store from the window manager (and Quartz libraries, etc., 
etc.) which is NOT something that every process has its own copy of. 
Basically any Quartz application running shares about 100-128 MB of 
that VSIZE with every other Quartz application running.

So in your example above, you're actually using something on the order 
of 120 MB of real memory, and not 231 MB.

A more realistic indication of memory utilization in a Quartz 
application would be to look at the RSS (resident set size) and then 
scale according to swap utilization.

ok
bear



More information about the rescue mailing list