🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: aus.computers.linux
Article #241

Re: Dual processors ?

#241
From: Lee Sau Dan
Date: Fri, 10 Jan 2003 08:09
98 lines
5477 bytes
>>>>> "Floyd" == Floyd Davidson <floyd@ptialaska.net> writes:

    >> make clean;time make bzImage

    Floyd> The above command ran in 2 minutes and 37 seconds, while

    >> make clean;time make -j2 MAKE='make -j2' bzImage

    Floyd> ran in 1 minute 28 seconds.

Have you tried both of these by booting with "maxcpus=1"?  The results
are useful  for comparison.  (Better  still, compile a  kernel without
SMP support, if you have the time to do so.)

BTW, even  the second  command is  not SQUEEZING the  most out  of the
system.   You'll  notice that  the  CPU loads  are  not  100% on  both
processors, due  to disk accesses,  etc.  -jn with  n >= no.   of CPUs
would help  to really saturate  the CPUs to  100% load.  I  have never
measured the time taken, but that's what I see with 'xosview'.


Don't take  me wrong.  I like  duals, and I still  have a dual-Celeron
300A  box.  I'm  not challenging  your figures.   I believe  the above
suggestions can make our arguments for Duals more convincing!

Costwise, I bought  the 300A when everyone was  paying high prices for
433 or 466.  So, the price of my dual-Celeron system is not that high.
I remember that  the price of a  466 cost at that time  almost twice a
300A.   So, I  pay not  that much,  but I  get 300+300  = 600.   And I
overclocked  each to  450MHz ==>  900MHz in  theory.  Even  assuming a
speedup of 1.5 instead  of the unrealistic 2, I still get  450 x 1.5 =
675, still faster  than the 466, not to mention that  a Dual system is
really much more responsive.

Yes, if I would pay the price  for 2 computers, I could get 2 separate
systems with 466MHz CPUs.  But  that's much more costly.  The CPUs are
so much more costly in the first  place.  Then, I need to buy 2 MBs, 2
harddisk, 2x  the amount  of RAM.  I  would end  up spending a  lot of
money.  So, if  you want to save cost and  still get high performance,
getting 2  not-the-fastest CPUs and  a dual-able MB may  actually cost
less than the fastest-of-the-day CPU.


    Floyd> We can surmise that if I pulled out 1 cpu, the first
    Floyd> command would probably run 1.01 times as fast, but the
    Floyd> second command would not be any faster than the first
    Floyd> (actually, because of all the context switching, it might
    Floyd> slow it down to 1.00 again).

No need to pull out 1 CPU.  Booting with "maxcpus=1" would be enough.


    Floyd> Since I commonly do things which heavily load the cpu's, I
    Floyd> very much enjoy the advantages of SMP.  Others might find
    Floyd> it a veritable waste of money!

Yeah.   It depends  on  usage pattern.   If  you will  be only  single
tasking,   duals  won't   gain   you  much   (although  still   gains:
responsiveness).  If  you have a lot of  CPU-intensive processes, then
surely duals help!

BTW, I'm not at home to try it on my dual-Celeron box.  You may do the
following experiments  and show  us the results.   I did these  when I
first set up my dual box and tested it:

        $ gzip -9 < /dev/zero > /dev/null
(time it with a stop watch)
        $ gzip -9 < /dev/zero > /dev/null & gzip -9 < /dev/zero > /dev/null &
(time it with a stop watch, too)

        $ gzip -9 < /dev/zero > /dev/null & gzip -9 < /dev/zero > /dev/null &
          gzip -9 < /dev/zero > /dev/null &
(time it with a stop watch, once more)


Let the  time taken be t1, t2,  t3, respectively.  On my  system t1 is
approx. twice  t2 (very  close: something like  1.99).  t3  is 3/2=1.5
times t2  (approximately).  The speed  up in this  artifically crafted
experiment is thus close to the ideal 2.0.


With  some imagination,  you could  use shells  scripts to  try higher
number of processes.  Something like:

        #!/bin/sh
        for i in "$@"
        do gzip -9 < /dev/zero > /dev/null
        done

would be fun to play with.  :D



-- 
Lee Sau Dan                     ���u��(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Technical Details
Message-ID: <m3znqagfkd.fsf@mika.informatik.uni-freiburg.de>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!yellow.newsread.com!netaxs.com!newsread.com!newsfeed.stueberl.de!feed.news.nacamar.de!news.belwue.de!news.uni-freiburg.de!not-for-mail
References: <pan.2003.01.03.13.58.10.249319@iprimus.com.au> <av578p$c8s17$1@ID-99293.news.dfncis.de> <av5qtf$tcf$1@lust.ihug.co.nz> <fbf82913.0301040421.1a35bdfa@posting.google.com> <3E178C63.7040901@netscape.net> <3E179C22.40306@iprimus.com.au> <8765t45jcu.fld@barrow.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 114381,acfea8e5e9ff6f15
X-Google-Attributes: gid114381,public
X-Google-Thread: 102b32,acfea8e5e9ff6f15
X-Google-Attributes: gid102b32,public
X-Google-Thread: 102983,acfea8e5e9ff6f15
X-Google-Attributes: gid102983,public
X-Google-ArrivalTime: 2003-01-10 01:45:03 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!yellow.newsread.com!netaxs.com!newsread.com!newsfeed.stueberl.de!feed.news.nacamar.de!news.belwue.de!news.uni-freiburg.de!not-for-mail
From: Lee Sau Dan <danlee@informatik.uni-freiburg.de>
Newsgroups: aus.computers.linux,comp.os.linux.hardware,aus.ads.forsale.computers.used
Subject: Re: Dual processors ?
Date: 10 Jan 2003 09:09:54 +0100
Organization: Rechenzentrum der Universitaet Freiburg, Germany
Lines: 98
Message-ID: <m3znqagfkd.fsf@mika.informatik.uni-freiburg.de>
References: <pan.2003.01.03.13.58.10.249319@iprimus.com.au> <av578p$c8s17$1@ID-99293.news.dfncis.de> <av5qtf$tcf$1@lust.ihug.co.nz> <fbf82913.0301040421.1a35bdfa@posting.google.com> <3E178C63.7040901@netscape.net> <3E179C22.40306@iprimus.com.au> <8765t45jcu.fld@barrow.com>
NNTP-Posting-Host: camaro.informatik.uni-freiburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=cn-big5
Content-Transfer-Encoding: 8bit
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7