Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!wuarchive!julius.cs.uiuc.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!rutgers!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Slow GVP '030 accelerator board
Message-ID: <16065@cbmvax.commodore.com>
Date: 26 Nov 90 21:53:45 GMT
References: <5801@crash.cts.com>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 53

In article <5801@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
>daveh@cbmvax.commodore.com (Dave Haynie) writes:
>>First thing you do, erase any copies of the Ronin CPUSpeed test you have 
>>around.  

>I totally agree with you here...but what I was trying to point out earlier is
>that IF the individual in question here WAS using that (or any similar)
>program, and only getting 20%, then something is wrong.  My own benchmarking
>program shows interesting things in this respect. [AIBB]. The Dhrystone on
>AIBB shows a 40% increase over an A2000 (68000 based) WITH both 030 caches ON,
>and about 15-20% at best with only the instruction cache on. [I haven't the
>heart to turn the instruction cache off ;-)] 

That's good; just about what I would expect.

>AIBB also has a few of those 'meaningless' benchmarks incorporated...and 
>they show higher to a degree...interesting what you can fiddle with here. 

I actually like the idea of what you seem to be doing in AIBB, though I haven't
seen the program.  Many moons ago, the now defunct Amiga Sentry enlisted my
help in benchmarking some competing 680x0 Coprocessor boards for the A2000.
It became clear to me that we needed a decent benchmark suite to compare
similar Amigas.  I came up with a simple series which basically ran three sets
of benchmarks.  The first set was traditional integer based artificial 
benchmarks, the second was traditional floating point based artificial
benchmarks.  The third was perhaps the most useful, as it attempted to
measure real-world performance.  It used the DBRender program, first as a
test of compiler performance, by building the actual program; next as a test
of application performance by running the compiled program.  I had a clever
script program which ran each benchmark, including FFP, IEEE, and '882 versions
of the floating point benchmarks (the last only ran if you had an '882) and
attempted to produce an automatic text file report of the results.  I have 
never had the time to perfect this, but I did see a need for it.  If you read
five different Coprocessor board reviews, you'll find five different sets of
criteria used to judge the boards.  Some standard, any standard, would be more
useful than the typical chaos.

>Yes...different compilers definitely show differences...and certainly what you
>get depends upon your compile options.  For benchmarks, many compilers have a
>tendency to optimize the benchmark code away, making them entirely useless. 
>In those cases, the benchmark no longer test machine performance, but compiler
>optimization efficiency.

Of course, one of the enhancements in Dhrystone 2.x was to at least use the
results of the benchmarks.  In 1.1, a sufficiently advanced optimizer could
avoid the whole benchmark by recognizing that the computed result was never
used.  I don't think any Amiga compilers actually do this, but you never know.

>--LaMonte  
-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
		      ONLY 230 MILES TO GO