Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Stellar 7 re-release
Message-ID: <10628@ucrmath.ucr.edu>
Date: 15 Dec 90 16:49:47 GMT
References: <3137.27692c59@miavx1.acs.muohio.edu> <41464@ut-emx.uucp> <1990Dec15.073350.20404@ee.ualberta.ca>
Organization: University of California, Riverside
Lines: 30

>> Do a DIR on a PC side by side a IIe doing CAT.

Hardly a fair comparison of CPUs.  All you're comparing is the speed of the
PC's BIOS (which is *horribly* slow) against the speed of the IIe's monitor
ROM.  For applications like word processing, the 8088 can update the screen
about twice as fast as the //gs due to the more reasonable layout of the
display memory.

Of course, who uses an 8088 @ 4.77 Mhz anymore?

>>Also note that on 8088's it took (takes!) 4 clock cycles to access memory.

One of the reasons the 286/386/486 chips run faster is that they access
memory in 3/2/1 cycles (depending on the processor).  This, of course, is
on top of the fact that the new processors access 16/32 bits at a shot).

>> 386 can do mults & divs in ~1-4 clock cycles.

Here you're giving the 386 (dunno about the 030) too much credit.  I beleive
the actual figure is 20 cycles.  Perhaps you meant microseconds (20 clocks
at 20 Mhz = 1 Usec).

One final comment about the sieve benchmark.  Back in 1983 everyone was
implementing the algorithm in exactly the same way.  Eyes and Lichty
optimized the h**l out of this thing.  The algorithm is not the same as
the one used on the 8088 in the Jan '83 Byte article.  I'm sure if we
ported the code to the 8088 and compare the results the 8088 wouldn't look
so bad (nor would the 4Mhz 65c816 look so good).

*** randy Hyde