Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long)

[Dave Haynie]

In article <392 at tcr.UUCP> xenon at tcr.UUCP (Chris Hanson) writes:

>    7) I have also run a rough benchmarking program (that supposably computed
>drystones per second) on the 3000UX/25, an 030 NeXT, and a DTK 80386/25
>running ESIX SysV R3.2.2. The NeXT averaged about 9000, the 386 about 12000,
>and the 3000 got about 3200. For comparison, the 3200 reading was from code
>compiled with the AT&T cc compiler. Compiling the same source with the GNU
>gcc compiler netted us a figure of over 6500. 

I think they typically get something like 8000 Dhrystone 2.1's per second
under AmigaOS using the SAS C compiler.  Are you sure you have the same version
of Dhrystone on these systems?  I could believe some extra software overhead
in UNIX, but not that much, unless you're sitting around paging, or the 
compilers are abysmal.  Also, the A3000 and '030 NeXT are very similar in
hardware terms.  With the same benchmark and same GNU compiler, I would expect
them to produce very similar results.  Either that '386 compiler has one of
these "Dhrystone detect features", or you're using a Dhrystone 1.1 and/or a
Dhrystone-sized cache on the thing.  That's the largest number I have ever
seen for a 25MHz '386 system.  In fact, that would be pretty good for a 33MHz
'386 in MS-DOS/take over the machine mode.

>    8) The 3000 (and UX) both have a very slick memory-processor
>architecture (Thank you, Dave Haynie!), but I have long wondered why a
>off-processor cache system was not implemented. 

Same reason its not on the NeXT -- cost.  The A3000 does have a place to put a
cache board, or, if you'd rather, a 68040 board.  These aren't available yet,
but I would expect to see something at least from the third parties (two
68040 boards for the A3000 are already announced but not shipping) sometime
this Spring.

>The 68030's internal cache is too small to be of much use in Unix, 

Actually, it helps out quite a bit, believe it or not.  The internal cache
isn't large, but it is efficient.  Since the 68030 has separate internal data 
and instruction paths, when both caches hit, you wind up doing fetches in
parallel where the pipeline permits.  When one hits, you may wind up hiding
some or all of a fetch to the main CPU bus by the other cache/fetch unit.
This sized cache isn't going to hold entire programs, but it's not bad on
program inner loops, or function calls (if you UNIX folks still push stuff
on the stack, call a function, and then pop it off).

>and it's duty in AmigaDOS seems to be to point fingers at those game 
>programmers who used self-modifying code. ;) 

Actually, it speeds things up considerably.  Keep in mind that the caches
aren't simply just caches, but they work with the 68030's burst/prefetch
mechanism.  So you load quadlongwords twice as fast with the cache being
used versus without it, even if you just manage to hit the 4 longwords in
that burst.

>Would a, say 256k SRAM cache significantly improve performance? 

Sure would.  External cache isn't as effective as internal cache, but it's
in general a good idea.  The cost police made an option.  Also, taking a 
careful look at the A3000 motherboard, if you find a place for it, I'll keep 
it in mind for the next generation :-).

>#define chris at kessner.denver.co.us Chris_Hanson|Lord_Xenon|Kelson_Haldane


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett