From: liljeber@hydra.Helsinki.FI (Mika Liljeberg) Subject: Re: Intel, the Pentium and Linux Date: Thu, 29 Apr 1993 08:06:23 GMT
In article <willmore.736040165@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) wrote:
> rabagley@termite.occ.uc.edu (Ross Bagley) 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.
>>
>>What? I'm thinking that you are a little confused, because what you stated
>>has little to do with the RISC paradigm. Per cycle... hmmm is that "per
>>instruction cycle"? If so then there are some problems with your statement.
>>First of all instruction cycles are not a good base to use for comparison
>>because one of the things inherent in RISC is a smaller instruction cycle.
>>Smaller instruction set -> simpler decoder -> smaller instruction cycle.
>
> You're right that I was a little vague. :) I had several assumptions that
> I didn't state. One thing that we should start with is that reality has
> little to do with the RISC paradigm.
>
> 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?
As far as I can tell, you're simply saying that RISC and CISC are like
apples and oranges, good but different. Why didn't you just say so? :-)
>>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.
This is not true. All modern processors have an onboard instruction
cache. A RISC processor doesn't waste any more memory bandwidth than a
CISC processor. If we assume that a processor can perform one load or
one store / clock cycle (not a rule perhaps, but certainly the usual
case), the RISC processor with its shorter clock cycle has a definate
advantage here.
> In fact,
> the memory system and memory interface will play a much more inportant
> part of this than the CPU architecture.
This is true, though. The memory bus does tend clog things up. Again,
that's why we have data caches. A RISC processor can move 1 word/clock
cycle provided that the data is in the cache. So can a CISC processor.
The difference is that a RISC processor has a much shorter clock cycle.
>>If you mean clock cycle, then there is no basis for comparison because
>>each design can use the clock however it pleases.
>
> No kidding? Geesh, you mean calling an Alpha 200Mhz doesn't meant that
> *everything* in that CPU system runs at 200Mhz? Really? As a matter of
> fact, the Alpha always clocks it's memory bus at one half of the CPU
> clock rate and in some cases as slow as one eighth the speed. Hmmm.
> To make it even more interesting, the R4x00 family does the opposite.
> They claim the cpu is 75Mhz when internally, it runs at 150Mhz. Only
> the bus runs at 75Mhz. Maybe you meant to say 'there is no *meaningful*
> comparison.' :)
I thought that's what he said.
> I admit that my remarks may have been confusing and misleading, but they
> weren't inacurate. ;)
I hate it when my teachers are confusing and misleading. :-)
Anyway, I do agree that the difference between the CISC and RISC
architectures performance-wise isn't as great or clear-cut as many
people would have us believe. The true attraction of the RISC
technology lies in it's faster development cycle and greater yields.
Ultimately the difference between processor architectures should be
measured not in SpecMarks, but in bang-for-buck. Because that's what
counts.
> I'm sorry for getting us all off the track. :) We'll now resume the normal
> Linux discussion.
>
> Later,
> David
Mika