Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.unix.amiga
Subject: Re: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long)
Keywords: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, etc.
Message-ID: <20073@cbmvax.commodore.com>
Date: 24 Mar 91 07:19:31 GMT
References: <19986@cbmvax.commodore.com> <1991Mar20.100122.1717@kessner.denver.co.us> <20030@cbmvax.commodore.com> <1991Mar22.053324.8867@kessner.denver.co.us>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 50

In article <1991Mar22.053324.8867@kessner.denver.co.us> david@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.

>Of course, this is all speculation-- as I don't realy know what the 386 UNIX 
>developers did.  (BTW, there are "smart" disk controllers that do use the
>DMA to it's full potential but I have not seen UNIX drivers for them).  
>Also, if ANYONE quotes the above paragraph in a 'followup' or 'reply'  PLEASE
>include this paragraph in the SAME QUOTE.  During the course of this discussion
>some of my remarks have been taken (unintentionally) out of context-- and I
>want everyone to know that the above paragraph is SPECULATION and any
>resemblance to any hardware (alive or dead) is purely coincidental...

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

>On the other side, none of the 386/25 (cached or not) figures I have seen (via
>the same method/sources as the 030/25's) were under 10,500.  It was closer to
>11,500 for cached systems.  This is all assuming that the 386 benchmark was not
>running under MS-DOG, where  the speed would be HALF that.  

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

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)