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

David Kessner david at kessner.denver.co.us
Mon Mar 25 07:29:02 AEST 1991


In article <20073 at cbmvax.commodore.com> jesup at cbmvax.commodore.com (Randell Jesup) writes:
>In article <1991Mar22.053324.8867 at kessner.denver.co.us> david at kessner.denver.co.us (David D. Kessner) writes:
>>Hmmm.  On the original AT, it was found that using a busy loop rather than 
>>DMA was faster (although I forgot the exact reason for this).  This was a 
>>reasonable thing on an MS-DOS machine, but isnt the greatest thing on a 
>>multi-tasking machine (BTW, an XT does use DMA on it's drives, but an AT 
>>does not.)
>
>	That's because it's via a DMA controller on the motherboard, and it
>(like the CPU) has to read a byte, then write a byte, over the bus.  In a
>single-tasking machine, it doesn't help any since it costs about the same
>number of transfers on the bus, and even the CPU is usually faster than the
>IO device, and ends up waiting on the port most of the time.  In a multitasking
>machine, the CPU often has something better to do.

Hmmm.  I depends on how the cache is designed.  I a well designed system the
system should allow DMA while the CPU is accessing the cache, and perhapse 
allowing the CPU to pause DMA and 'burst reload' the cache.  I doubt that
the current lineup of ISA based 386/486's do this, however.

FYI:  In the current issue of PC MAg they review 486/33 ESIA machines.  They
range in price from $5700 with a 200 Meg HD, Mini-Tower case, 128K cache, up
to 96Meg on the MB, also includes SVGA of sorts, but I dont know the RAM/Video
configuration for the price mentioned...

>	These are probably "bus-mastering" (also called "first-party") dma
>controllers.

I would not say that...  I would call it "pathetically simple DMA".

>	Note that 80x86's are do better on dhrystone than they do on larger
>or more general benchmarks: dhrystone is heavily string oriented, and the
>strings don't match real-world characteristics, but do match the string
>functions of '86's (or so I'm told, I'm no expert, and I don't do 80x86's).
>SPECmark (particularily for Unix) is a _FAR_ better benchmark.  As for your
>request for source, ask in comp.benchmarking - it's an entire tape's worth
>(gcc is just one of the tests).  BTW, as for the '040 vs '486 vs SPARC:
>all at 25Mhz, all 128K cache, the '040 gets 11.8 SPECmarks (12.9 integer,
>11.0 FP); the '486 gets 8.8 SPECmarks (13.3 integer, 6.6 FP); and SPARC gets
>11.8 (12.3 integer, 11.6 FP).  (SPECmarks are essentially VUPS: Vax 11/780
>units of performance.)  (Source: Feb 20 Microprocessor review, also posted
>by the author in comp.arch.)

I have found a source of other benchmarks, like whetstone, linpack, etc.  I'm
still looking for the SPECmark.  I'll check comp.benchmarking.

The only CONCLUSIVE evidence that the dhrystone has told us is that the 
386 can compute dhrystones faster than the 030 at the same clock speed.  
However, this may indicate that there are some applications that the 386 
will run signifigantly faster.  I'll post results from other benchmarks as
become available.

Re: 486vs040...  Initial figures for the 040 are scarse and contain a lot of
marketing hype.  The 486, however, has a bit more information.  It's integer
UNIT is a tad more than twice as fast as the 386, and floating point is three
times as gast as the 387-- which brings it up to about 1.5 MFLOPS.  All reports
that I have seen suggest that the 040 is roughly equal to the the 486 in
integer, and a lot faster in floating point.  Your figures agree with this.

AND IT"S ABOUT TIME.  (assuming that the 386 is signifigantly faster than the
030)  It is sad that a less-than-optimum design [the 386] could be faster than
a clener-better-designed cpu [the 680x0].  I wondered why the 030 was slower,
and am encouraged by the inital performace figures of the 040.  The 386 is a 
decent CPU, as is the 486-- but GOD knows that IBM wans os/2 extentions in the
next generation 80x86's so its future is unknown (unless you want os/2)...
I'll stop ranting now...

>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
>{uunet|rutgers}!cbmvax!jesup, jesup at cbmvax.commodore.com  BIX: rjesup  

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



More information about the Comp.unix.amiga mailing list