🚀 go-pugleaf

In article <1992Nov15.010845.25121@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:
>In <1992Nov13.165319.11391@crc.ac.uk> ifenton@crc.ac.uk (I. Fenton) writes:
>
>>i didn't write the numbers down, but i think that the low-end ALPHA
>>box is a 133MHz job which gives a specint92 of about 70-ish (?).  from what
>>i remember the 486-50MHz has a specint92 of around 30.  so, MHz for MHz,
>>alpha seems no better than a 486... or i am a twit ?!
>
>MHz for MHz the 486 has very good integer performance. The R3000 is a little
>better, but many other RISCs aren't. The 486 has much poorer floating point
>performance than RISCs, but this isn't relevant to most DOS applications.
>

Since the 486 is also pipelined to a point where it have almost 1 instruction
per clock cycle it will always be just as fast as a RISC, MHz for MHz.
BUT I would like to see you make the 486 running at 200MHz. The 
RISC structure allows you to build RISC's running at higher clocks
than CISC's with the same production technology. This is the major
performace advatage the RISC's have.
Futher I would  like to see INTEL superpipline their x86 family at the
same pace at the RISC manufacturers.

>Intel has been doing a good job keeping their "market niche" happy. (Can you
>call their overwhelming market share a "niche"?)
>
>I'd like to hear from RISC architects and implementers on this topic. Given
>all the touted advantages of RISC, why aren't they blowing Intel away? The
>bottom line is that Intel has kept up with RISC much better than most RISC
>companies thought they would.
>
>Just to get things going, I'll throw out my pet peeve. It's been discussed
>here before. But since I haven't been in a position to gather numerical data,
>I'll have to stick with "intuition". (Yes, very un-RISC-like).
>
>My pet peeve is the direct-mapped caches used in many RISCs. Implementers need
>to reexamine this slavish devotion to the gospel according to Hennessy &
>Patterson. The H&P conventional wisdom is that a set-associative cache would
>slow down the machine clock by more than the equivalent performance gain.
>However, driving large numbers of signals off-chip is becoming more difficult
>as clock rates increase. Fast external SRAMs are very expensive. The mismatch
>between processors and DRAM is getting worse each year. These trends argue for
>set-associative caches both on and off chip.
>
>As a counterexample to the dogma of direct-mapped caches, I submit that one
>important reason the 486 performs so well is its 4-way set-associative primary
>cache. It does so well that many systems are sold without an external cache.

I do not intend to get my self into a discussion on different 
cache structures, but it is my "intuition" that it is the size that by 
FAR determines the cache hit rate. Cache structures play a much bigger
role in small caches like with the 486 2x 8kbytes. RISC boxes have typically
 >256k secondary caches. But you touches some keys issues here. INTEL
have survived partly because of the DRAM and I/O barriers, 
you don't gain that much by increasing the clock.

No the main reasons for INTEL continued success is program availability,
and price (both software and hardware). Even if you can claim that 
the 486 CPU can keep up with the RISC's every thing around it in the PC
is wastly slower. Which in turn gives the price, a 486 PC is prices at about
a fifth of a work station. You get complete 486's now for $1000, while 
a low end SUN goes for $5000, with out a disk. 
A good example is the SUN 386 roadrunner. It died because the CPU
speed was about half of a SPARC, while the roadrunner box was priced
higher than half of the price of a low end SPARC at the time.

Do I really need to give a discussion on the software situation.
For the 486 there are wastly more applications priced significantly
lower (which is also easily "copyable") while for RISC boxes the
same applications are much higher priced, and protected by far
superior  licence schemes.
Remember, software cost are usually much higher than the hardware cost.
I have experienced one case where it was cheaper to buy a 486 and the PC
edition of a program than buy the Sun edition.

This is why the x86 family and MSDOS will continue to haunt us for the 
next two decades, probably more.


Terje
    _________    _________    _________
   /         \  /         \  /         \
   |         |  |         |  |         |   Terje Eggestad
   | FORTRAN |  |   VMS   |  |  MSDOS  |   t0e0078@tamsun.tamu.edu
   |         |  |         |  |         |
   |   RIP   |  |   RIP   |  |   RIP   |    "A dollar saved is a dollar 
   |         |  |         |  |         |     wasted"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%    --- Thomas Edison
-- 

    _________    _________    _________
   /         \  /         \  /         \
   |         |  |         |  |         |   Terje Eggestad