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

[David Kessner]

In article <19887 at cbmvax.commodore.com> daveh at cbmvax.commodore.com (Dave Haynie) writes:
>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.

I am the owner of the 386/25 mentioned in Chris Hanson's original artical, so
here is my two cents worth... 

The same Dhrystone program was used on all of these machines.  They were
compiled with the standard GNU compilers on the NeXT and A3000UX, and with
GCC Version 1.36 on the 386/25.  On the A3000 and 386/25 the only compiler
option specified was "-O".  I dont know what options were used on the NeXT,
as a friend did it for me.

I know that this is an Amiga group, but perhapse some of my 386 UNIX 
experiance is worthwhile.  The 386/25 has a 64K external cache-- which is
larger than the dhrystone program.  This test was ran under UNIX and MS-DOS.
Under MS-DOS, it got 8000 dhrystones/sec which can be attributed to the 16
bit regesters and added instructions that REAL 386 code can use. 

In the magazines "UNIX World", "UNIX Review", and "Personal Workstation" they
rate several machines and include dhrystone figures.  It is intersting to note
that all of their figures are consistant.  They rate most 386/25's (cached) at
12,000/sec and 030/25 at 8000 (give or take 500/sec).  

>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.

My machine (the 386/25) can accomodate 64K or 256K cache.  The version with
256K was rated as best price/performance UNIX workstation by "Personal
Workstation" for quite some time (until the 486's came along).  FYI, the 
upgrade to 256K cache is $350.

I think that C= could have made an external cache more accessable-- especally
for the UNIX machine.  In that market, the extra $300-400 for a decent cache
would not be missed...

>>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).

The internal cache has trouble keeping up with multitasking operating systems
such as UNIX (and to some extent AmigaDOS).  I would not be suprised to see
the cache effectively dumped when an intterupt is serviced.  In addition, 
hand optimizing a loop to fit in the cache is rarely done on UNIX, where it
is almost standard under AmigaDOS.

>>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.

Yes-- however, a well designed external cache can also use the many 
burst modes that todays DRAM support (page mode, static column, or even
64 bit wide data paths).  Granted, all this costs-- but I'd pay for it.

>>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 :-).

FYI, there are 486 motherboards that can handle 512K of cache.  That would
be nice! :)

>>#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

					- David K
-- 
David Kessner - david at kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);