From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Intel, the Pentium and Linux Date: Sat, 1 May 1993 03:12:02 GMT
In article <willmore.736040165@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) writes:
> >>There are just too many factors at play to be able to say that. A well
> >>designed CISC should *always* be able to execute more instructions than
> >>a RISC processor *per cycle*. The differences lie in that the CISC chip
> >>will have taken much more work to design and won't be able to be run at
> >>the clock speed that the RISC processor can.
> >
>
> For a RISC processor to execute a job equal to one CISC instruction, it has
> to execute quite a few more instructions. A RISC processor will take more
> cycles to complete the same amount of work than a CISC processor. So,
> measured in CISC instructions, a CISC processor gets more CISC instructions
> done per cycle than a RISC does. The catch is that the RISC can execute
> much more quickly and has much more flexible control of the CPU.
>
> Make sense?
No. The comparison is not that simple. It is true that a given CISC
instruction may require may RISC instructions in order to accomplish
the same work, but that can be very misleading. RISC chips tend to
have many more registers, so they can often get by with less loads and
stores. RISC chips also tend to have 3 operands so you can do
"Ra <- Rb + Rc" in one instruction, where a typical CISC processor will
have to execute an extra move instruction.
This can mean that for a given C routine, a RISC processor
may require _less_ instructions than a CISC processor. Comparing
things by what it takes to implement a given C routine is much more
meaningful than comparing what it would take to make an equivalent
instruction.
You will also find that optimizing compilers will tend to remove many
of the "extra" instructions that are required to make "equivalent CISC
instructions" out of RISC instructions. A CISC processor may have a
load instruction with lots of fancy options to calculate the memory
location, but with a good optimizing compiler, these fancy addressing
modes tend to not be used as much. The added complexity of the CISC
processor is wasted.
All in all, RISC processors only execute about 5-20% more instructions
for a given routine, but because the RISC instructions are all fixed
sized 32 bits instructions instead of nice short 8-16 bit
instructions, the code size is usually 10-30% larger.
>
> >Third, a CISC processor running a single large complex instruction (such as
> >string copy) may (in many cases will) take longer than a RISC processor
> >running a program segment to do the same thing. This is at the same clock
> >speed and with equivalent clock dividers or whatever in place to make it
> >fair. This is because a RISC compiler can remove many test cases at
> >compile time which the CISC processor must test every time the instruction
> >is called at run time.
>
> Not likely. More likely a modern CISC processor would win because (at the
> same clock speed) there are fewer instruction fetches (i.e. none) in the
> CISC case and therefore less memory bandwidth wasted for I fetch. In fact,
> the memory system and memory interface will play a much more important
> part of this than the CPU architecture.
Sorry, but these anomalies are fairly common on CISC processors.
Since these complex instructions have to be implemented in microcode,
they basically run a RISC-type instruction sequence and often, for a
variety of reasons, these microcode routines either are not, or can
not be implemented as fast as the equivalent series of RISC
instructions. (Often, in order to execute the microcode, you have to
flush the pipeline, or the microcode can't be pipelined, etc)
In fact, it is so bad, that on a CISC processor, there are often
complex instructions that are slower than the equivalent series of
simple CISC instructions for that same processor. This is true on
various VAX, 68000 and x86 processors. The Intel 486 manuals even
point out that using the "JCXZ" instruction "takes longer to execute
than [the equivalent] two-instruction sequence". You would think that
there would never be any instructions like this on a CISC processor,
but it turns out that these anomalies are all too common. The Pentium
will probably have _may_ such sequences. You basically have to
program the Pentium as if it was a RISC processor and avoid all those
fancy instructions like the plague.
As far as memory bandwidth for instruction fetches, the RISC chips do
not come out too badly. First, there are usually on chip instruction
caches which minimize the memory bandwidth used, and secondly, the
extra RISC instructions are almost always sequentially located in
memory. You don't usually fetch one instruction at a time, you tend
to fetch an entire cache line. RISC processors simply tend to have
slightly longer cache lines and the time it takes to fetch an entire
cache line is not that much longer. The memory bandwidth issue is at
best very minor.
If you take a look at the specmarks/Mhz of various RISC and CICS
processors, the RISC processors often get more work done at the same
clock speed. Examples:
System CPU Clock Cache SPEC SPEC SPEC SRate SRate Info Source
Name Type (MHz) Ext+I/D 92Int 92 FP Mrk89 Int FP Date Obtained
====== ====== ===== ======= ===== ===== ===== ===== ===== ===== ============
Intel486 80486 50 256+8 30.1 14.0 Oct92 c.arch
iPentium Pentium 60 256+8/8 58.3 52.2 Mar93 comp.arch
iPentium Pentium 66 256+8/8 64.5 56.9 Mar93 comp.arch
IBM 580 RIOS 62.5 59.1 124.8 126.4 Mar93 c.s.sun.hw
SS10/51 SP/Vik 50 1M+16/20 65.2 83.0 1847 1930 Apr93 Sunflash
HP 715/50 PA1.1 50 37.1 72.8 69.0 866 1710 Apr93 Sunflash
So, not only are RISC processors able to run at much higher clock speeds,
they get more real work done per MegaHertz. The also tend to be
available earlier to boot. (i.e., the above compares systems that
have been shipping for a while with the pentium processor that still
isn't out yet...)
> Trust me, the only way to clear this up if for everyone out there to take a
> class like the one that you mention. I've taught one before. [ ... ]
>
> I admit that my remarks may have been confusing and misleading, but they
> weren't inacurate. ;)
hmmm... well, I only hope you taught things more accurately, and with
less confusion than this...
-wayne
-- Well intentioned, knowledgable people with shape minds can disagree on something without either one of them being unreasonable, or necessarily wrong. Too often people assume that other person has ill intentions, is unknowledgable or doesn't have a sharp mind.