[luau] Re: PPC vs. X86

[Eric Jeschke]

On Sat, 28 Dec 2002 Jimen Ching wrote:

| Date: Fri, 27 Dec 2002 22:59:48 -1000 (HST)
| From: Jimen Ching <jching at flex.com>
| To: luau at videl.ics.hawaii.edu
|
| [snip]...
| I heard the opposite.  I heard the higher clock rates of the Pentium
| 4's give you no advantages.  I heard clock rates of 800Mhz is all you
| need for home use and most business use.  I also heard that an 800Mhz
| PowerPC outperforms an 800Mhz Pentium II/III, and consumes less power.
| Of course, performance benchmarks these days are heavily dependent on
| other things besides CPU clock rates, like cache size/speed, and other
| processor theories not related to the master clock.

Disclaimer: architecture is not my main area.  But I have a PhD in
computer science and taught a 400-level undergraduate computer
architecture course just last spring, so I have at least one leg to
stand on here... 

What you "need" for home and business use depends one what you do
obviously.  In your email you said you were going to do multimedia/
development (i.e. builds/compiles, run codecs, etc.); this sort of use
would definitely benefit from higher clock speeds.

The higher clock speeds of the Pentium and Athlon processors definitely
give you an advantage over the *much lower* clock speeds of the G4.  The
G4 currently tops out around 1GHz (I believe).  You are correct in
assuming that the superior RISC design (with a smaller pipeline, but
more issue/execute units) of the PPC will give you better performance
than a P4 or Athlon *that are in the same ballpark*.  i.e. a 1GHz PPC
would probably outperform a 1.3GHz P4 and maybe even a 1.5GHz P4.
This is same reason that a 1.6 GHz Athlon was outperforming a 2.0GHz
P4. BUT P4's are currently topping out above 3GHz!!  You have to build a
dual processor PPC system just to be in the ballpark.  Yes, cache, FSB,
presence of L3 cache, etc. do make a difference, but for compute
intensive code running out of the L1/L2 cache (codec loops, compiler
optomization passes, etc.) having a higher clock will definitely help
you out--the PPC (even though it is retiring more instructions/clock) is
just not able to keep up.  I saw a recent review (sorry don't remember
where) of a dual 1GHz PPC against a 3GHz P4 with hyperthreading; the Mac
lost on every benchmark.

If you are doing I/O bound work rather than CPU bound work then, yes,
you should save your money and buy a slower processor because it will be
waiting most of the time anyway...
|
| >Don't get me wrong: I love my iBook running Yellow Dog Linux; but for
| >browsing the web, email and similarly non-compute intensive tasks (I
do
| >curse the CPU at times :-)
|
| Isn't the iBook still using G3 processors?  I believe these processors
max
| out at 600-700Mhz.  But most of the G3 systems I've found doesn't come
| anywhere close.  What is your processor speed?

Yes the iBooks are G3s.  The clock speed on mine is 500MHz, I believe.
Yes, the G3 to a G4 is like a P3 to a P4.  Yes, G3's don't have Altivec
acceleration or Velocity architecture of the G4.

On a laptop, a high processor speed will eat into your battery life.  I
was not planning on doing anything "heavy" on the laptop, so it works
out to save me a lot of juice.

| >IMO, if you want to run Linux on a desktop or a server x86 is the
   clear
| >way to go at the present time.
|
| I think this used to be the case.  But after doing some research, I
| found out a few things.  First, Apple's hardware seems to be really
| under powered.  If you do a search for the Macs that came out between
| 2000 and 2001, they are all G3 based, and under 500Mhz.  There doesn't
| seem to be any good reason for this.  Second, I found lots of
| information on upgrading your PowerMacs.  Clearly, Apple's customers
| also think the hardware coming out of Apple is under powered.

I don't agree with this.  They are tracking the top of the PPC
manufacturing pretty closely.  Witness: the dual 1GHz G4 is their
current top of the line (they have been beating Motorola's door down
trying to get them to build a faster chip, but Motorola does not have
the market/fab/capitalization/design/?? to ramp the architecture up as fast
as Intel and AMD).  Even AMD is conceding the 32-bit performance crown
to Intel, because nothing AMD has now in the 32 bit line is touching the
P4's performance. 

| At this point, the only advantage that x86 have over PowerPC is the
| software.  There are clearly more software available for x86 than
| Macs.  But for Linux, this advantage disappears.  Of course, Linux on
| PowerPC is not as mature as Linux on x86.  But for the parts that I
| care about, it's close enough.  ;-)

Well, I have noticed the advantage even running Linux.  If you are going
to compile everything yourself, this may not be an issue.  But it's much
harder to find PPC RPMs than x86 RPMs.  Also, some codecs that I've got
running on my Athlon are not working on PPC because they use
MMX/SSE/SSE2 optomizations.  Some are available for PPC but use generic
C code and so are not nearly as optomized.  I notice this e.g. trying to
build Xine or Ogle or VLC for PPC.

As someone else, pointed out, the distros are running about 1 or 2 revs
back on PPC vs. x86.  For example, Yellow Dog Linux 2.3 (their latest)
is based on Redhat 7.2, I think.  They do backport a lot of stuff,
including newer kernels, etc. but the whole distro "feels" old compared
to, say, Redhat 8.0.

One last thing: you mentioned that Firewire was competitive to SCSI (in
your quoted email).  Not to my understanding or experience.  Firewire
tops out at 400 Mbps or 50 MBps.  Even IDE has a better transfer rate
than this.  Firewire is nice in that it is hot-plug; you can also do
RAID tricks over firewire to increase the performance, but a good
high-speed SCSI subsystem (or even IDE) will be much superior in terms
of performance. 

Of course if you want a PPC because it is a "beautiful" architecture I
totally understand.  I preferred the beautiful 680x0 architecture back
when it was competing with the "ugly" x86.  But I'm just trying to help
you out on the basis of performance/flexibility/price.

--Eric

-- 
Eric Jeschke
http://cs.uhh.hawaii.edu/~jeschke