Article View: comp.os.linux.hardware
Article #492Re: Dual Celeron's and SMP Performance Problems
From: kuhn
Date: Fri, 28 May 1999 00:00
Date: Fri, 28 May 1999 00:00
139 lines
6602 bytes
6602 bytes
In comp.os.linux.hardware Totally Lost <idletime@my-deja.com> wrote:
: Ok, we'll use your numbers... $1000 system, with an additional $150
: that is 15% more, not 50% more, for that you get a 10-20% speed up,
: a very small part of the time (doesn't speed up editing, backups,
: installs, web browsing, or most other single command activities that
: we occupy our time with in front of the computer). It does however
: speed up a few tasks that some people do frequently.
My Calculation:
Price SpeedUp
2xCeleron333 PC $1150 60-80%
2xPentiumII/350 PC $1700 70-90%
=> the Pentium-System is about 50% more in price, but only
10-20% more in speed - application depended.
At least at my benchmarks (compilation, povray)
: I suspect that if the human wait time was more carefully analyzed
: across the spectrum of users, that reductions on Disk I/O or network
: connectivity would have have a bigger payback. For most people,
: an additional $150 spent on a faster disk subsystem would save them
: a lot more time than the meger saving of a dual processor. Or in many
: cases, simply selecting the next faster uniprocessor model which would
: shave a little off every activity, not just multi-process ones.
Speed requirements to the I/O-System are also application depended :-)
Aside the speedup of a second processor, a Dual-System is more
reactive than a single-CPU-system, as two interrupts can be serverd
at the same time.
:> : Did you try SpecWeb, NetBench, WebBench
:> : or TCP-C benchmarks which by most industry standards represent a
:> : "heavy load"?
:>
:> Not yet. Please give me the URLs for those, and i will do them.
: If you have to ask that question, I suspect you can neither afford
: them or have the skills to install and run them to get meaningful
: results.
That is what i was pointing out: those benchmarks are not
available for everyone :-(
So i can only bench what i am usualy doing :-)
:> I was talking about the Brain-Dead intel-Architecture inside
:> and outside the CPU! (Even with a MC68000/8 you can
:> stand harder real-time requirements than with an PIII/500
:> - application depended)
: I'm not that fond of IA32, it's kinda haphazard. But it's far
: from Brain-Dead.
Ok, lets say it is Semi-Brain-Dead. :-)
: I've done several Motorola hardware designs with MC68008 and MC68020
: chips myself, and worked on quite a few more. There are parts of IA32
: that are not pretty, but there is nothing to back up your absolute
: claim here. Polling both have similar latencies, the PIII/500
: is a lot faster. Interrupt latencies are a little more predicable
: with the Motorola products, but in terms of absolute margins, the
: faster external bus clock cycles of the PIII/500 wins hands down.
The PIII are faster, of course, but they are absolutly
non-deterministic - that is ok for many applications, but
for i.e. machine controll it may be totaly insufficient
(because of the unpredictabilaty).
Intel even can't give out the execution times for
assembly commands - not because they don't want to,
but because they simply don't know. they only can
give out liklyhoods! That is insufficient for some
hard-realtime applications.
Ok, 99% of the users may be satisfied, but why flooding the
earth with inferior technology?
: In the end it's not the instruction set, bus architecture,
: or glue logic that really matters, it's what the end users can see and
: do with a system.
i.e. downloading pornographics? :-)
Would you be satisfied with a steam machine in you car?
: From that perspective, Intel is at least as good, if not the hands
: down winner, at providing a usable computer into a wide range of
: computing and non-computing professionals.
Millions of flys can't be mistaken: shit has to taste well!
:> But for what i (and many others) am doing at home, the celerons
:> are the better choice!
: That's every buyers choice to make for themselves ... and hopefully
: an informed choice at that. Blanket recomendation of one particular
: techology with a total disregard to the application is folly. Hence,
: my warning that dual celerons might provide a good bang for the buck
: for certain users, but *DO* not blindly accept that they are fast
: for everyone, or even a reasonable cost/performance tradeoff for most
: people. In general, I strongly assert they are a poor choice for most
: server applications, given that for a few percent more there are better
: PII/PIII/Xeon uni/multi-processor options that can handle modest/large
: loads *MUCH* better for the buck.
I never stated that Dual Celeron is a suitable solution for
anyone. At least a Dual Xeon may also not fit the users needs ...
Thousand times: it is application depended:
i.e a dual 21264/500 is faster than an ocat PIII/500 at floating-
point applications, but little slower at integer once. It doesn't make
sense to say which is the "better" machine.
--
-------------------------------------------------------------------
| Bernhard Kuhn (kuhn[at]lpr.ei.tum.de) O|||OO||OO| |
| Laboratory for Process Control and Real-Time Systems O|||O|O|O|O |
| Technische Universit�t M�nchen Tel.+49-89-289-23732 O|||OO||OO| |
| 80290 M�nchen, Germany Room 3944 Fax -23555 OOO|O|||O|O |
--------------------------------------------------------------------
Technical Details
Message-ID:
<7ilr3u$r6s$1@sparcserver.lrz-muenchen.de>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<7ieko6$41e$1@nnrp1.deja.com> <7ifeih$8i6$1@sparcserver.lrz-muenchen.de> <7ik5io$4s0$1@nnrp1.deja.com> <7ikd09$cfi$1@sparcserver.lrz-muenchen.de> <7ikk51$fgu$1@nnrp1.deja.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 100562,acbefbd0f12f9cdd
X-Google-Attributes: gid100562,public
X-Google-Thread: 102b32,acbefbd0f12f9cdd
X-Google-Attributes: gid102b32,public
X-Google-Thread: 1159f7,acbefbd0f12f9cdd
X-Google-Attributes: gid1159f7,public
From: kuhn@lpr.e-technik.tu-muenchen.de.nospam
Subject: Re: Dual Celeron's and SMP Performance Problems
Date: 1999/05/28
Message-ID: <7ilr3u$r6s$1@sparcserver.lrz-muenchen.de>
X-Deja-AN: 483064619
Distribution: world
Content-Transfer-Encoding: 8bit
Sender: Bernhard Kuhn <kuhn@ernie.lpr.e-technik.tu-muenchen.de>
References: <7ieko6$41e$1@nnrp1.deja.com> <7ifeih$8i6$1@sparcserver.lrz-muenchen.de> <7ik5io$4s0$1@nnrp1.deja.com> <7ikd09$cfi$1@sparcserver.lrz-muenchen.de> <7ikk51$fgu$1@nnrp1.deja.com>
Content-Type: text/plain; charset=ISO-8859-1
Organization: Lehrstuhl für Prozessrechner, TU München
Mime-Version: 1.0
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (Linux/2.2.6 (i686))
Newsgroups: comp.os.linux.hardware,alt.comp.hardware.overclocking,csu.unix.linux