Re: CISC vs RISC concepts -- from an assembly view
- From: spamtrap@xxxxxxxxxx
- Date: 26 Apr 2006 11:13:19 -0700
HellsRaison wrote:
Now this question just popped out of my head. I'm viewing this as a C
program to an x86 assembly output.
CISC CPU speed is relied on microprocessor optimizations (like 3DNow!
and MMX, SSE2, SSE3 extensions/optimizations) which are enabled by the
compiler.
These are just technologies to increase ALU operations per instruction
density. These technologies are enabled either through inline
assembly/intrinsics or in limited ways through straight compiler
capabilitiers. I would like to point out that AltiVec is an
instruction set extension (comparable to MMX + 3DNow! or SSE-1) for the
PowerPC which has the same relationship in terms of intended
capabilities and compilers.
And RISC CPUs rely their speed on _compiler_ optimizations (converting
the least amount of operations done with what the user is trying
accomplish.
This is certainly the propaganda. The point here is that RISC
processors break things down to such simple pieces that the compiler
translates to more but simpler and more uniform base instructions. So
the compiler can apply its techniques more generally since it has fewer
things it needs to think about when its analyzing the instruction
stream its produced.
But being hard to do, is not the same thing as impossible. There is
more of a market for x86 compilers, so vendors are able to invest more
into their creation. I think that there is no question that state of
the art x86 compilers such as Intel's are easily comparable to the best
RISC compilers out there.
If there is one flaw that you could point to in the x86 that hurts them
with respect to compilers, its that up to and including the 32 bit
instruction set, the number of registers has been pathetically small.
Fortunately for the x86, excluding loop unrolling, the number of
registers you need for a given function is roughly proportional to the
logarithm of the size of the inner loop. Nevertheless, its very often
a very tight fit to try to actually perform a whole inner loop with the
x86's paltry register set.
So if this is true, shouldn't everyone be using RISC processors and
just use really smart compilers to create their executable. [...]
Why don't you ask Intel how this strategy is working out for them and
their Itanium line of products? Look, marketshare drives investment in
improvements, which improves the products serving those markets. Even
giving Intel the possibility of leeching from their x86 profits to fund
improvements to their Itanium compilers and systems in general, the
x86s are still wiping the floor with IA64.
x86 is the king, because its had the strongest and most sustainable
market growth. So much so, that even the transition to 64 bits, where
you would assume that the market would be most vulnerable is going to
be relatively smooth (thanks to AMD), and has not brought on a
resurgence of any alternative microprocessor architecture.
[...] Because
that way the RISC can go extremely fast (1:1 ratio of CPU Cycles :
Operations -- or at least close to this), and all of the advanced math
stuff (that Intel uses -- SSE2, SSE3) would be embedded within the
executable output.
In theory, the ratio is even *better* with modern CISC. Processors
like Opteron and Pentium-M execute the majority of their instructions
in one clock as well, even though they do more things in a single
instruction (like implicit flag computation and complex memory
addressing and ALU operations.)
See, this is part of the RISC propaganda. But stating one natural
aspect of RISC, it is implicitely assumed that matters must be worse
for the CISC people. But its just not the case.
Am I thinking clearly and realistically?
No. You've been fed propaganda from one side of the argument, and for
some reason believe it.
RISC is easier for CPU *designers*, and its easier for compiler
developers in the sense that they have a very narrow set of
instructions that they need to output. However, the advantages stop
there. Noteice that those aspects are *not* exact embodiments of
overall performance.
x86 has certain instruction set advantages that are leveraged in modern
microarchitectures. Its market dominance is without question, and this
means that Intel, AMD, Microsoft, PathScale or whoever can justify more
expendatures in order to improve the whole x86 environment. The
competition between AMD and Intel alone has driven long lasting and
sustained performance improvements that are unheard of amongst RISC
vendors. If either of AMD or Intel eventually conceeded that they
couldn't do x86 CPUs anymore, that would dramatically curtail their
business -- so both companies are highly motivated to deliver.
RISC vendors typically competed with incompatible competitors, and so
were able to leverage infrastructure lock-in, rather than being forced
to compete vigorously. You could argue that there was some of that
with IBM and Motorola on the PowerPC, but these companies seemed
perfectly willing to trade off ownership of the Apple account rather
than engaging in a direct comfrontation with each other to try to
dominate that business. Motorola eventually just got out of that
business, and Apple has given up on the PowerPC. The Sun and Fujitsu
competition on Sparc can hardly be taken seriously.
Even the most successful RISC architectures (as measured by their
performance) like the Alpha, eventually went away because they simply
couldn't sustain a profit. In all cases the parent companies making
RISC processors were not as committed to the success of their CPUs
because it wasn't their core business.
So in the end, CISC (more specifically, x86) wins because there is more
money in it, which means there is more investment in improvements. And
this spans from microarchitectures to compilers.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
.
- References:
- CISC vs RISC concepts -- from an assembly view
- From: HellsRaison
- CISC vs RISC concepts -- from an assembly view
- Prev by Date: Re: GNU AS and multiplatform example ...
- Next by Date: Re: CISC vs RISC concepts -- from an assembly view
- Previous by thread: Re: CISC vs RISC concepts -- from an assembly view
- Next by thread: GNU AS and multiplatform example ...
- Index(es):
Relevant Pages
|
