Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!gatech!uflorida!codas!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: For a good time, read...
Message-ID: <2737@pdn.UUCP>
Date: 7 Apr 88 14:44:30 GMT
References: <7841@apple.Apple.Com>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 30

In article <7841@apple.Apple.Com> bcase@Apple.COM (Brian Case) writes:
>There is a wonderful article in EE Times this week.  Starting on page 49
>and continuing on page 54, the article, entitled "CISC beats RISC in test,"
>sumarizes the results of a battery of tests performed by Neal Nealson &
>Associates.  They compared comparably-configured (say it three times fast)
>workstations.  The SUN-3 was a 25 MHz CPU with 16 Meg of memory.  The other
>computers were the two models of the IBM RT (slug city), the Intergraph
>32C (slightly less sluggish), the MIPS M-500, the SUN-4, and HP's 9000 and
>825.  

The other point that Nelson & Associates made was that the Sun-3 was
faster than most or all of the RISCs on some of their integer math
benchmarks (regardless of the number of running processes).  They pointed 
out that the apparent reason for this was that THEIR integer benchmarks
force lots of register-memory data shuffling (instead of keeping most
data in registers for extended periods).  They contend that this is the
more common case in business programming (I have no opinion on that).

What do y'all think of the proposition that business programs do more
memory-register data shuffling?  Could that cause a shift in the
"balance of power" between CISCs and RISCs?  Why or why not?  And if
not, how do you explain these results? Are their benchmarks simply 
flawed? (Careful, these people have a good reputation for knowing what
they're doing/talking-about).   

If Nelson & Associates have published the source code for their
benchmarks, perhaps someone could post them to the net for our
edification?

-- Alan "Inquiring minds want to know" Lovejoy
-- alan@pdn