Re: The RISC penalty

John Levine <compilers-request@iecc.com> writes:
>[I looked at Pittman's ``The RISC Penalty'' article, ... I'm not
> amazed at his conclusion that 68K chips run 68K object code better
> than RISCs.]


Probably true, but that wasn't his conclusion.


The article reported that a 68K *interpreter* written in RISC code had
a theoretical cost of 68 cycles, not including cache misses, and that
a dynamic cross-compiler for the same function produced code that
theoretically ran in 18 cycles. Indeed, for small bemchmarks, good
speedups were observed using the dynamic cross-compiler. However,
when run on one real x86 application (unnamed, code size not
specified), the dramatically larger code generated by the dynamic
cross-compiler ran *slower* than the interpreter code, because the
instruction cache miss rates were terrible with the larger code.


I believe that one of Pittman's conclusions was that code-expanding
transformations (``optimizations'') are less likely to be successful
with a RISC because they're already running ``close to saturation'' of
the instruction memory bandwidth. In short, that there IS a space
cost for code, and that RISC, with its larger code, is limited by the
space cost sooner than some other architecture (Pittman proposes stack
code, which is probably great for integer ops, but I'm unclear about
fp, which tends to work better when pipelined).


BTW, this isn't the first time Pittman has noted the space cost:


%A Thomas Pittman
%T Two-Level Hybrid Interpreter/Native Code Execution for Combined
Space-Time Program Efficiency
%D 1987
%J ACM SIGPLAN
%P 150-152


Three pages and well worth the read.


;-D on ( Me and my spacey costs ) Pardo
[All true, but when you look at his code examples, they have all sorts of crud
due to having to emulate details of the 68K architecture. I didn't see much
evidence that his observations would be applicable to other kinds of programs.
-John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.