Re: The RISC penalty

iank@dircon.co.uk (Ian Kemmish)
28 Dec 1995 11:52:47 -0500

          From comp.compilers

Related articles
The RISC penalty d.sand@ix.netcom.com (1995-12-09)
Re: The RISC penalty cdg@nullstone.com (1995-12-17)
Re: The RISC penalty pardo@cs.washington.edu (1995-12-18)
Re: The RISC penalty pardo@cs.washington.edu (1995-12-19)
Re: The RISC penalty jbuck@Synopsys.COM (1995-12-20)
Re: The RISC penalty pardo@cs.washington.edu (1995-12-21)
Re: The RISC penalty iank@dircon.co.uk (1995-12-28)
Re: The RISC penalty dlmoore@ix.netcom.com (1995-12-28)
Re: The RISC penalty meissner@cygnus.com (1995-12-30)
Re: the RISC penalty john.r.strohm@BIX.com (1995-12-30)
Re: the RISC penalty pmk@pmk.mn.org (1995-12-31)
| List of all articles for this month |

From: iank@dircon.co.uk (Ian Kemmish)
Newsgroups: comp.compilers
Date: 28 Dec 1995 11:52:47 -0500
Organization: The Direct Connection
References: 95-12-063 95-12-077 95-12-103 95-12-112
Keywords: architecture, performance

pardo@cs.washington.edu (David Keppel) writes:


>His group built a tool that instruments DEC Alpha/AXP binaries for
>Windows NT and also instruments Windows NT itself. They then ran the
>binaries and gathered ``snapshots'' of instruction and data references
>from the programs. The workload was SPEC92 and a TPS benchmark. Once


It's difficult to construct an experiment that *only* measures
the effect of instruction size on cache hit rate.


However, it is possible to contruct a very similar experiment, that
measures the effect of going from 32 bit pointers to 64 bit pointers,
by running the same benchmark code on an Alpha, running Windows NT and
then running OSF/1 (oops, sorry, they're calling it DEC UNIX this
week:->).


I did this recently, and the difference in performance was <5%.


Unfortunately, until someone ports pixie to NT, it's impossible to
*know for sure* the numbers of instructions being executed in each
case, but both compilers are advertised as using the same code
generator, and a lot of the inner loopy code *looks* the same on both
OS's.


[The benchmark was the Jaws PostScript interpreter running the most
recent verion of the PPST PostScript benchmark. As a RIP or printer
benchmark, PPST is not so hot, but it does exercise the cache...]


--
---------------------------------------------------------------------
Ian Kemmish 18 Durham Close, Biggleswade, Beds SG18 8HZ
ian@five-d.com Tel: +44 1767 601 361
--


Post a followup to this message

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