🚀 go-pugleaf

Floyd Davidson wrote:
> Michael <mutk@iprimus.com.au> wrote:
> 
>>BTW, the performance isn't twice as great on a SMP system. There is 
>>overhead, resulting in SMP system being something less than twice the 
>>performance.
>>
>>
>>In a nut shell, a SMP Linux system running on 2X 1800 Athlons will 
>>always  be superior to a uni-processor 1800 AThlon machine due to the 
>>fact that a typical Linux system has many processes running 
>>(Multi-threaded or not). But the performance advantage of 
>>multi-threaded app is *much* greater than a single threaded app on a 
>>SMP system.
> 
> 
> Here's an example.  I compiled the kernel using two different
> commands (twice each, to make sure the times were valid).
> 
>   >make clean;time make bzImage
> 
> The above command ran in 2 minutes and 37 seconds, while
> 
>   >make clean;time make -j2 MAKE='make -j2' bzImage
> 
> ran in 1 minute 28 seconds.
> 
> Basically, by taking advantage of both cpu's the compile was 1.8
> times as fast.
> 
> We can surmise that if I pulled out 1 cpu, the first command would
> probably run 1.01 times as fast, but the second command would not
> be any faster than the first (actually, because of all the context
> switching, it might slow it down to 1.00 again).


In my single cpu , Celeron 850 system:
time make bzImage

real    14m38.567s     14.63333333 minutes
user    9m54.688s
sys     0m45.307s

time make -j2 MAKE='make -j2' bzImage

real    12m2.053s      12.03333333 minutes
user    9m34.289s
sys     0m35.525s

Its around 1.2 times as fast.



On a higher spec CPU like a Intel 1.6 Ghz its the same:

time make bzImage

real    5m40.801s     5.666666667 minutes
user    4m21.785s
sys     0m16.617s

time make -j2 MAKE='make -j2' bzImage

real    4m38.795s     4.633333333
user    4m10.613s
sys     0m12.344s


My explanation:

The system was very under utilised. The load average for the system 
running first make command was always around 2.8 and the cc1 process 
would only ever use at most ~30% of CPU.

Using the second  make command (-j2) I could see as many as 6 cc1 jobs 
in top, each getting ~ 9-12% of CPU, and the load average was up 
around 5.2. So by launching several jobs (Threads) the CPU would be 
more effectively utilised. In other words it's a resource hog.

BTW, if you pulled one CPU out you will get much worse than 2 minutes 
because the cc1 job will get less CPU time.

> 
> A single cpu machine, compared to a dual cpu machine, will
> provide an unnoticable speed increase (that may be measurable),
> if and only if only one process is running on the machine.  But
> a dual cpu machine can compile the kernel as much as 1.8 times
> as fast on a heavily loaded machine.

Exactly. However, it still stands that the CPU can be more effectively 
utilised if multi threads are used. The advantage is not anywhere near 
  what SMP system achieves and is also very dependent on the CPU load. 
It's clear SMP systems have an advantage.

Also, this is ONLY relevent to CPU intensive things . IO performance 
is still tied to system BUS and devices, RAM access speeds et al.

> 
> Whether a dual cpu is cost effective depends entirely on how
> often one can actually load it down with enough work to see any
> benefit.  And as one poster noted, that is less likely with
> today's faster cpu's than it was a few years back.  When running
> the X server took up 30% of the cpu power, having 2 cpu's made a
> very noticable difference for a single logged in user just in
> command line responsiveness.  I haven't tried it, but I suspect
> that if I pulled one cpu out of this box I would not notice a
> difference in command line response more often than once a week.
> 
> Since I commonly do things which heavily load the cpu's, I very
> much enjoy the advantages of SMP.  Others might find it a
> veritable waste of money!

Yes. If you do things like run a web server, VMware session, Mozilla 
(Resource HOG) and build from source all at once, an SMP system will 
be nice. If you run just Mozilla, and Open Office.org, there is still 
an advantage, but not so significant.

Cheers,
Michael