Sorry about the format - will fix ASAP.

Running on a Mac Book Pro, Core 2 Duo, 2.33Ghz, 3GB RAM.
Machine was idle aside from Fusion virtual machine running.

I would expect 2 CPUs to run 2 threads at less wall clock time than 1 CPU.

I would not expect 2 CPUs to require significantly longer wall clock time than 1 CPU
for an increasing number of threads.

Hope this helps..
Thanks,
/jim

The test case is a simple C program that spawn a number of threads (pthread_create()), specified as a command line argument.
Each thread is exactly the same - the threads loop doing some integer arithmetic seeded with a random number. The threads run
through a fixed number of loops, and exit. I use ptime(1) to get the wall clock time for the run.

I agree that 2 CPUs are not always better, but there's no locking in this test code - just CPU-bound threads.
For this test case, I would expect 2 CPUs to result in less wall clock time. At the very least, I would not
expect it to be pathologically worse, which it is.


I will post the source code for the test case ASAP - I need to clean it up a bit...

I should add that the reason I embarked on this measurement process in the first place is because
I observed that using Solaris with 2 CPUs configured was generally worse, in terms of
sluggishness, responsiveness, etc. In other words, my observations were initially that "this thing
just doesn't work well when 2 CPUs are configured", and that lead me to measure it.

Thanks very much.
I will post the test case later tonight.

/jim

Thanks Pat - Just to be clear, are you saying that you do not consider this behavior a bug?

If that is the case, I most respectfully disagree. I certainly understand and agree with the point you
made - more cores, less contention, better SMP performance. Nonetheless, running 2 threads
on 2 vCPUs taking 2X longer than 2 threads on 1 vCPU, all other things being equal, is,
IMHO, a bug.

I don't have a support agreement, so I can't file an SR on this, so I suppose this
is as far it goes.

Just so we part as friends, I'm quite happy with Fusion overall....

Thanks,
/jim

The source code is attached. It's a bit of a mess, as a carved it out of a larger source file that I use
to generate CPU, IO and memory load for demos on Solaris (showing dtrace and performance tools),
so there's some cruft in there...

Compile as "cc -o tloader tloader.c".
Here's run output, 32-bit VM, 2 vCPUs - note I use ptime(1) to get wall clock time.
FYI, I did track this with a stopwatch to account for the fact that timers get skewed on
virtual machines.

32-bit kernel, 2 vCPUS:
mau
nv70b> ptime ./tloader 1
Starting 1 CPU threads

real 0.857
user 0.837
sys 0.016
nv70b> ptime ./tloader 2
Starting 2 CPU threads

real 3.917
user 6.838
sys 0.505
nv70b> ptime ./tloader 4
Starting 4 CPU threads

real 8.661
user 15.369
sys 1.389
nv70b> ptime ./tloader 8
Starting 8 CPU threads

real 17.784
user 31.633
sys 3.026

Note going from 1 thread to 2 threads, with 2 vCPUs, increased wallclock time by a factor of 4.5X !
That, my friend, is pathological behavior.
Note in the 1 vCPU results below, going from 1 thread to 2 threads is almost perfectly linear - increase
of 2, which is expected.

32-bit kernel, 1 vCPU

nv70b> ptime ./tloader 1
Starting 1 CPU threads

real 0.865
user 0.842
sys 0.009
nv70b> ptime ./tloader 2
Starting 2 CPU threads

real 1.693
user 1.661
sys 0.011
nv70b> ptime ./tloader 4
Starting 4 CPU threads

real 3.473
user 3.370
sys 0.020
nv70b> ptime ./tloader 8
Starting 8 CPU threads

real 6.772
user 6.641
sys 0.031

In the next few weeks, I'm upgrading to Leopard (currently running 10.4.11). With Leopard, I'll have dtrace, so I may be
able to learn a bit more about what's happening with scheduling in OS X and Fusion at that point.

C code source file attached. Please post question, comments, findings, etc. I will post more as I learn
more.

Thanks for your interest and time.
/jim