Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/448b.lha/AIBB_v1.0/AIBB.doc

Text File | 1990-12-08 | 16.1 KB | 313 lines

     Popular Hangouts:

         AmiHolics BBS: [phone]
         N.A.G. BBS: [phone]
         AmigaFriends BBS: [phone]
         F.A.U.G. BBS: [phone]
         Amazing Connection BBS: [phone]
         Amiga Micro BBS: [phone]
         Codename Lorraine BBS: [phone]
         PSA BBS: [phone]
         It's A Hard Drive! BBS: [phone]
         Miller's Amiga BBS: [phone]
         [Sheesh...maybe I should tone down a bit :-) ]

You can also post a public echoed message on IntelecNet, and I will
generally see it, and I also lurk here and there on USENET.
And YES, I DO want your comments and suggestions.

If you REALLY need to contact me, or feel the urge to send me large sums
of money :-), I can be reached via the U.S. Snail...um MAIL service:

                         LaMonte Koop
                   565 Park Meadows Dr. #302
                     Waite Park, MN  56387

Also...I'm always looking for something interesting to do...so if you have
something in mind, let me know.  If it's within my capabilities, I'll
probably give it a whirl.  I probably will even if it's not within my
current capabilities...I'll just wing it and learn :-).

--------------------------------------------------------------------------

Now, for the LEGAL [ohhh..gasp..quiver with fright :-) ] stuff:
   First of all, this program is freely distributable.  You may pass it
along as you wish.  BUT, I don't want you going around claiming it's your
program...that's fairly standard.  Since it isn't one of those programs
you'd use EVERY day, I won't call this shareware, or ask for a donation,
but if you feel so inclined, it would be much appreciated...developing
things is costly on occasion.  But if you can't afford to, or whatever,
you may go about with a clear conscience. [Now aren't you glad I said
that? :-) ].

DISCLAIMER:  I take no responsibility if this program begins eating
important things on your HD, or does anything destructive.  If it somehow
results in a small thermonuclear explosion...well, I don't think you'll be
thinking about complaining, but I still don't take responsibility.  Now,
don't let this scare you off...the program really shouldn't be capable of
anything destructive...and hasn't killed yet, so ENJOY!

---------------------------------------------------------------------------

On to the fun stuff (the program):
[NOTE: I'm AWFUL at writing docs...be warned! :-) ]

     Basically, this program is a combination of several benchmarks put
together with an Intuition interface.  Currently, six tests are supported;

The Sieve test:
     This is a version of the standard Sieve of Erathosthenes benchmark.
It finds the prime numbers in a range from 0 to 8190, many times over in
a loop...quite simple.

The WritePixel test:
     This is a test of the speed of the ROM routine WritePixel, and is
based upon the test by Computer Systems Associates.  It uses
this routine to draw a box on the screen, one pixel at a time, then erases
it in the same manner.  It is generally useful for comparing Amigas which
have their ROM kernel mapped into 32-bit RAM, using an accelerator, to
test the effective speed of the ROM routines in this memory medium.

The Sort test:
     A standard Shell-sort algorithm is used to sort an array of 12000
numbers into order.  To create the array, I did not use random numbers, as
this could easily invalidate the machine comparisons, depending on how
disordered the numbers generated were.  Instead, I used an algorithm to
'mix' the numbers, so they will be generated the same every time, insuring
accurate results from test to test.

The Matrix test:
    Performs Matrix addition and multiplication functions on 3 40x40
matrices using integer numbers.

The Savage test:
    Is a real-number test, and an oldie but goodie. It computes a number
of trancendental functions, and real-number operations on a single number
many times over.  It uses the Motorola Fast-Floating Point (FFP) functions
in the MathTrans.Library. (I didn't use double-precision numbers because
I didn't want the presence of a '881 or '882 to affect the figures....I
may do a coprocessor set-up later).  Now, there is a version of the
MathTrans.library that was re-written by someone which uses the
capabilities of a 68881 or 68882 math coprocessor.  If you have, and are
using this library, you will get comparison figures which are WAY off
base.  In a way, this could also be useful for testing the difference the
mathco makes in this test...

The Dhrystone test:
    Probably everyone recognizes this one.  It's the standard Dhrystone
benchmark, and will return a result in dhrystones/second instead of
a time result.  I've noticed that in all the implementations of the
Dhrystone test, there is no single 'dhrystone performance level' that
every version centers around.  The same machine, at a given machine, may
show 2000 dhrystones/second on one test implementation, and 3000 on
another. (or more/less)  This is mainly due to the compiler used, and
other variables.  Not to worry...this is not a problem here.  Since what
this program is basically showing is the percentage, or ratio of
performance between machines, using it's version of the dhrystone test,
the comparisons are valid. [The RATIOS of test performace from the
different test implementations are generally in a given range, even if the
actual figures are different]

I intend to update these and add more as time goes on...

HOW TO OPERATE THE PROGRAM:

   The program is designed to time your machine through the various tests
you select, then compare the results with 3 other machines:  An Amiga
2000 (stock), an Amiga 2500/30, and an Amiga 3000 (25MHz version).  The
total time for the benchmark will be shown in the 'BenchMark Result'
column (with the exception of the Dhrystone program, which shows
dhrystones/second)...lower time numbers mean better performance, except
for the dhrystone test, where higher numbers indicate better performance.
Four other display boxes show the percentage of the various machines'
performance compared to the base machine being compared to...the default
base machine is the Amiga 2000, which will show 100% in it's column.  The
percentages work like this:  Each box shows that machines percentage of
performance compared to the base machines... i.e: the 2500/30's percentage
compared to the base, etc. (Your machine/base comparison is shown as
well...).   The base machine will always show 100%...as it is comparing
it's performance to itself.  You can change the base machine from the
menu...more on that in a bit.  Results will also be graphed into a
vertical bar graph, with the base machine always = 1.0 on the graph scale.
If the numerical box percentage output is still unclear...just think of
it like this:  Say you just ran a test with the A2000 (default) as the
base...then each box will show the percentage performance of that machine
vs. the A2000.  The A2000 box shows 100% because it is comparing it's
performance with itself.  [I do ramble don't I?]

The machines used for the comparisions:
    The A2000 figures are based upon an A2000 utilitzing FAST RAM.  This
means that if you only have CHIP RAM, or SLOW-FAST RAM (for those of you
with a 512K Agnus) at $C00000, your speed tests may show a slight
performance reduction, should you choose to benchmark your machine against
the A2000 ratings here.  The processor [68000] was of course running
at it's usual 7.14MHz, with the program residing in the FAST RAM area.
All RAM on the A2000 was by necessity 16-bit (just thought I'd mention
the obvious... :-) ).
    The A2500/30 comparisons are for an A2500/30 fitted with a 25MHz
68030 microprocessor, with 2 megs of 32-bit RAM. Dave Haynie's SetCPU
was used to move the ROM Kernel into this 32-bit medium, with the program
also running in the 32-bit environment.
    The A3000/25 figures are for the A3000 fitted with a 25MHz 68030, 2
megs of CHIP RAM, and 3 megs of FAST RAM.  The expansion FAST RAM in this
case was of standard DRAM variety. This means that if you have fitted an
A3000 with either Static-Column or Page-Mode DRAM for expansion FAST RAM,
your machine may run faster.  You can try to determine the approximate
speed increase by checking your machine against the A3000 here.

Requirements:
   You must have the 'MathTrans.library' in you libs: directory to use
the Savage benchmark...if you don't, the program will tell you it cannot
find the library, and will disable the Savage test...all others will still
function.

   Not to difficult...but here's an overview of what functions are
available.

*************************PROGRAM FUNCTIONS********************************

GADGETS:
   Tests are selected from the six test gadgets located in the
lower right corner of the screen.  Click and wait :-).

MENU FUNCTIONS:

     These take a little explaining.  Under the menu, there are
two items of very special interest;  Quick Test, and Be Selfish. Please
read the following fairly carfully.

Quick Test:
   This informs the program that you are in a hurry...it affects the Sieve,
Savage, and Dhrystone tests by reducing the number of iterations performed
by the tests.  It will go faster, but the results will be less accurate.
(The comparisons with other machines will not be adversely affected, as
the program will take the differece into account, but nevertheless, it
will be less accurate).  HOWEVER [there's always one of these :-) ], there
will not be very much of an accuracy loss in the Sieve test when using the
quick option.  Basically, the reason for this is that with the 'Quick'
option enabled, the only thing which is changed about the Sieve is the
number of iterations performed.  On most systems, the quick test will thus
return a time which is a scaled time of what the long test would return.
In other words, the test behaves in a mostly linear fashion time-wise in
relation to the number of iterations performed.  Now, in systems using
cached memory a great deal, this linearity in test results may suffer, so
the long test is the best choice.

Be Selfish:
   This menu item is very important.  The Amiga is quite a
difficult machine to benchmark, as programs running in the background
under the OS will affect the results, due to the lost time from task
switching.  Even the 'unnoticed' OS background functions steal a little
time.  Be Selfish attempts to rectify this.  When checked (selected), the
program will basically halt the multitasking in your machine.
The benchmark then becomes the only task to be allowed CPU time.
NOTE:  Your pointer will freeze, and even
the ever-popular disk clicking will stop while a test is running with the
Be Selfish option.  DON'T PANIC!  The machine has not hung.  This is
perfectly normal.  Give the benchmark time, as when it finishes the
program will re-enable multitasking,  returning things to normal.  If
you want accurate results, use Be Selfish. THE TEST FIGURES FOR THE OTHER
MACHINES FOR COMPARISON WERE ALL OBTAINED WITH THE 'BE SELFISH' OPTION
ENABLED, SO IF YOU WANT ACCURATE COMPARISON RESULTS, IT SHOULD BE
ENABLED!!! [Sheesh...I'm hoarse. :-) ].  The only real reason to disable
it would be to test the multitasking drain on a system.
NOTE: sound programs, etc... running in the background will 'freeze' on
the particular sound they are playing at the instant the test is
started...again, don't panic, they will resume when the test finishes.

Change Base: (As promised)
     Basically, selecting one of the sub-items from this menu
item changes the base machine for comparison to the one you selected. The
'Base machine=' box in the info area will show this change.  This is
basically useful if you want to get a more accurate picture of how your
machine rates against one of the others, instead of the generic 'All vs.
the A2000' test.  For instance, if you select the A2500/30 as the base,
all machines will be compared against the A2500/30's performance,
including yours...percentages in the percent column will reflect this, and
the graph will be calibrated towards the A2500/30's performance figures.
Simple enough...useful if your machine is VERY close to one of the other
machines, and you want to get a picture of the true performance compared
to that machine...not both compared to the A2000 or such.

About:
    A neato-keen little requester will appear with the standard 'About'
    stuff.

Quit:
    Need I say more? :-)

***************************************************************************

And that's about it.  This program does use a fair amount of memory
(nothing hideous, but don't be running it with only 30K left in your
system). 50-100K free is a good guestimate. [It doesn't really use that
much for the tests at any one time...but the screen and window(s) do take
up CHIP RAM and such.]

SOME MISCELLANEOUS NOTES:

     As I mentioned before, the A2500/30 and A3000 figures within the
program that are used for the comparisons were obtained using the
'Be Selfish' option...just a reminder.  For the A2500/30, The ROM image
was residing in 32-bit RAM, and the program itself was running in the
32-bit RAM area.  The A3000 already has a 32-bit ROM interface, so no
translation was required...the program was run in that machine's FAST RAM
area.  Both machines were using the 1.3 version of the OS, with
EVERYTHING possible enabled.  BTW: I don't really think leaving the
Instruction Cache off for ANY test is really a fair comparison, as the 020
and 030 rely heavily upon it. (The OS will even switches it on
automatically for you)  In fact, in some circumstances, leaving the
Instruction Cache off while operating within 16-bit memory will leave you
with a SLOWER computer than with a standard 68000. (The explanation is a
bit long-winded for a doc file...but go ahead and run a program in 16-bit
memory with an 020 or 030 with any/all caches off...you'll see what I
mean.) Why see them when they are slightly diabled...it defeats the purpose
of having an advanced processor in a system.  This can be argued with
me...and I may even change something if you feel strong enough about it to
contact me and convince me.

    The program will show what CPU is running in your system, below the
graph area...as well as any FPU it detects.  Unfortunately, it uses the
OS to determine this...under 1.3, if you have a 68030, and the system has
not been informed of it's presence it will register a 68020 only.  Don't
worry, your expensive 68030 has not transmuted into an 020...  I'll
'unlazy' myself one of these days and code in something a bit more
accurate here...bang on the Cache Control Register (CACR) to see what
the machine actually does have----So this is not really a 'bug', just
laziness on my part.  (Many accelerators' support programs DO inform
the OS of an 030's presence, so this may not show any problem for you, and
even if yours doesn't, YOU know what's in your machine, and the erroneous
report will not affect the tests one way or another.).  This program WILL
recognize a 68040 [Where's MINE?!? :-) ], and will report N/A in the
System FPU area, as the 040 has a floating-point unit built on-chip.

Well...that about takes care of the docs.  If you find them too confusing
(as I said...I'm horrible at writing docs), let me know and I'll have them
re-written.

Note on the use of 1.3 vs. 2.0:
   As I mentioned earlier, 1.3 was used on the comparison machines, not
2.0 (mostly in the case of the A3000 is this relevant at this point).
When 2.0 is widely available, I will put out a new version, should
interest exist, with new comparison figures.  It seems that 2.0 DOES
significantly make a difference on most of the benchmarks.

A final word on the comparison figures:
  ALWAYS take comparison figures with a grain of salt.  Who knows...maybe
the machines I obtained my baseline figures on were completely messed up.
If so, LET ME KNOW!!!!!!!!!!!!!  I will endeavor to correct the problem.


A few THANK YOUs are in order:

First, to Mark Manes, who helped with acquiring the baseline figures for
the A2500/30 and A3000...
Mical Todorovic, who shed light into one of my tiny boo-boos, to him
you can thank for not having to use a horrendously large Stack setting.
And Michael Walters, whose tips and debugging help were much appreciated.


'Nuff said...enjoy the program!

"Let me talk to Whosit...give me a few Whatsits...and by golly I'll make a
 Whatchamacallit!!!"--LaMonte