home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
458.lha
/
AIBB_v2.01
/
AIBB2.doc
< prev
next >
Wrap
Text File
|
1991-01-04
|
49KB
|
786 lines
Amiga Intuition Based Benchmarks
Version 2.0 ©1990 LaMonte Koop
This program is designed to test various aspects of CPU performance
on your Amiga. I must note that the tests used are for evaluating CPU
perfomance ONLY, and not math coprocessor performance. FPU support is not
included in this version, but may be in a future release. The comparisons
made within the program are designed to be a 'General' type of comparison.
They are far from 'exact to 0.000000000xx percentage or somesuch.
Because of the nature of computer systems, and the fact that differences
can occur between two machines of the same type, the comparisons I make
should be used as an average view of the systems compared. Many comparison
samples were used to gather these figures, and most come within a good
proximity of the values. The conditions under which these values were
obtained is explained in the documentation below. If you want to REALLY
be sure of the comparisons, ideally you should run the tests on your
machine, record the time value each test displays (the time the test took
to run), and do the same thing to the machine you wish to compare to,
and evaluate the results. This program will give you an average result
answer however, allowing you to make general comparisons with other types
of accelerators and machines. Please do read the subsection under menus
describing the 'Be Selfish' option...there are some warnings you MUST
read there. As with all benchmarks, a certain environment had to be set
up for the base results used for the comparisons. Please do read the
sections pertaining to the environment used for the base machines in
AIBB's comparisons.
Legal Information: (gasp...choke...)
Amiga, all Amiga models, and Intuition are trademarks of Commodore-Amiga Inc.
MC68000, MC68010, MC68020, MC68030, and MC68040 microprocessor designations
trademarks of Motorola Inc.
Disclaimer: I make no guarantees that this program will be accurate. I
have made every attempt to make it so, but I cannot be held
responsible for its accuracy, and/or consequences of such.
(In other words, include standard disclaimer here :-) )
Also, should this program maim and/or destroy various aspects
of your Amiga, I am also not responsible. (Well...it hasn't
killed yet...): Another meaning; if you run this program, and
something about it surprises you, causing you to
spill coffee into your machine, which sends a power spike
feedback through the power lines, down to your local power
station, which subsequently explodes in flames...,
I don't, and never did exist. ;^)
This program has been a GREAT deal of work...I consider it to be of a
'Share/Free' ware type of release. I make no REQUIREMENT that a donation
or fee be sent, but if you find it very useful, anything would be
appreciated (cars...spare Amiga 3000s...large sums of cash :-) ).
In any case, AIBB is NOT PUBLIC DOMAIN! You may not change it or modify
it...and certainly don't call it your own program...
That'd really bug me <^_^>.
-----------------------------------------------------------------------------
PROGRAM REQUIREMENTS:
This program can be used on any Amiga...but there are a few requirements
to use all of it's features. First, to use all of the test features, it
should be started with a stack setting of 12000. The icon included will
do this for you, or you can do it yourself from the CLI. Second, in order
to use the Log File saving utility, you must have either the arp.library,
or req.library in you libs: directory. Please read the appropriate sections
below for more information on these topics. Note that these requirements
are not in actuality 'requirements' for the entire use of the program, but
rather for certain features of it.
USING THE PROGRAM:
This program was designed to be fairly easy to use...which is the
reason I utilized an Intuition interface. Basically, test options and
such are selected from menu items, and a test is intiated by selecting
it's gadget on the screen. Again, note that the comparisons made in this
program are meant to be general. Here's an overview:
Menu Items:
The menu fields in the menu bar for AIBB are as explained below:
The 'General' menu:
About:
This simply shows my neato little 'about the program and
life in general' requester. Fairly standard stuff.
System Status:
A few key points of interest about your system will be displayed.
Among them are:
Exec library version: (aww...why not? :-) );
System Stack location: The system stack on the Amiga is normally
located in either CHIP (for 1+ meg CHIP RAM machines), or SLOW-
FAST RAM (for 512K CHIP RAM machines). There are programs
available which will move the system stack into FAST RAM. This
allows the system to access said stack area without possible
contention occuring on the CHIP RAM bus, and can somewhat
improve system performance. [Not a GREAT deal, but anything
counts :-) ].
Memory Information: Your currently available CHIP and FAST
ram is displayed, along with figures denoting the largest
available contiguous chunk of said memory types. These
'chunk' figures are important, as AIBB allocates memory for
certain tests, and if a large enough contiguous memory area
is not available in FAST RAM, the system will search the memory
lists until it finds one (or fails), and just may allocate the
memory in a slower medium.
Start/Stop Log File:
This will allow you to activate/deactivate AIBB's saving of
test results. [The menu will show 'Start' when you are
currently NOT saving results, and 'Stop' when you are]. When
first selected, AIBB will call up a file requester asking you
for the name of the Log file to use. Currently, 2 file
requesters are supported...the one found in Colin Fox & Bruce
Dawson's requester library (req.library), and the standard
ARP requester library...you will need either the req.library
or arp.library in your libs: directory to have access to this
saving feature [Worry not...I'm writing my own requester as
well, and will probably make an update AIBB with it, if you
do not want these shared libraries]. AIBB prefers the
req.library requester, and will first look for it...it then
will attempt to gain access to the arp.library...If it cannot
find either of these, it will disable this menu function.
When a file is selected, AIBB first checks to see if it exists.
If not, it will create it, writing the identifier 'AIBBLogFile'
at the head of the file (standard text file). All future test
results will be appended to this file, until 'Stop Log File'
is selected, or the program exits. [Note: it is NOT necessary to
stop file logging before exiting...it is mainly there if you
wish to make another file]. If the file you select DOES exist,
AIBB will check the beginning of the file for the 'AIBBLogFile'
identifier...if it finds this, it will again append all results
to the end of this file (nothing will be overwritten)...if AIBB
does not find the identifier at the start of the file, a
requester will pop up warning that the file is NOT a standard
AIBB log file, and will ask you if you wish to cancel the
operation, OR use the file anyway. Be careful..this warning is
designed to keep you from writing over important files...or
programs. [NOTE: AIBB WILL write into a binary file if told
to continue...I will add some better checking in the future, but
for now, WATCH the warning!]. About the file requesters:
Personally, I find the one in the 'req.library' much more
appealing...try that one if you at all can. The next version of
AIBB will support the AmigaOS 2.0 standard file requester as well,
and will favor that one over the others it checks for. Note that
AIBB does not buffer results...it writes to the file as soon as
a test is completed. This shouldn't be too much of a problem,
but if people find it irritating, I will of course add in some
buffering. If desired, RAM: or a recoverable RAMdisk can be used
to save results, but care should be taken that the space the
file takes will not use up FAST RAM to an extent that the
test results will be affected.
Quit:
Self explanatory. (I hope)
The machine will be placed back into it's baby original
state when the program exits...regardless of the manipulations
which may have been done during the tests (See the section
on 680x0 cache manipulation)
The 'Test Options' field contains:
Be Selfish:
This is an important item. Basically, when this is
selected, the program will make sure no other tasks
are given CPU time while one of the tests is running.
In this way, you are assured that the test results will
reflect true CPU performance, and not lag due to other
tasks taking up some of the CPU's time. All of the
comparison figures for the other machines were obtained
with this option ON (A check will be placed by the
option when it is active), SO IF YOU WISH TO COMPARE
TO THE OTHER MACHINES IN THE PROGRAM MOST ACCURATELY,
HAVE 'Be Selfish' SELECTED!!! <whew>. Read on...When 'Be
Selfish' is active, the system will not respond to you
while a test is running. Meaning, you will not be able
to move your mouse pointer, and that most enjoyable
floppy drive 'clicking' will even stop. THIS IS NORMAL!
You will regain control when the test completes...the
system did not hang. Some tests do take a little time,
so hang in there. The only time you will really not
want to have 'Be Selfish' active is if you wish to
test the performance drain on your system from having
multiple tasks running. (or just to see what the normal
load of tasks does to your CPU performance). Now...you must
know something about this option. What I do when this option
is enabled is invoke a Disable() call a bit befpre each test,
and then an Enable() afterwards. Disable() effectively STOPs
all interrupts within the system. Since multitasking is
interrupt-driven, this is also stopped, and my task becomes
the only one doing anything (there are exceptions...that is
explained later). ALL this aside, I MUST give you a warning.
I designed this program to test CPU performance, and as such it
is a good idea to have as little running in the background as
possible...aside from performance issues though, there are
some programs/operations which are very timing sensitive. If
you are running one of these in the background, then DO NOT
use 'Be Selfish'...I suggest just waiting until you are done
with that operation before using this program. This is
especially true of Disk-based operations...it is possible that
if you are doing a large r/w operation on your Hard Drive, or
floppy, and run this program with 'Be Selfish' enabled, you
could run into problems. To be safe, just consider such things
a no-no. NOTE: AIBB's own file saving is done in a safe way,
and CAN be used with 'Be Selfish', as the program only accesses
the disk when not performing a test.
Anyway, since you want to use this program to test CPU
performance, it is best to run it basically alone. The program
defaults to NOT using Be Selfish so that the quick-to-jump-in
person will not feel my program has locked-up the system when
they go to do a test. The first time you select 'Be Selfish'
from the menu, a requester will pop up reminding you of what
I just said here. Once the requester has appeared the
first time, it will not appear again during the course of the
program's execution, regardless of how you set the Be Selfish
menu option (otherwise it could become quite annoying :-) )
Now, with 'Be Selfish' NOT enabled, there are no restrictions
to this program's use, but again you will show a marked
performance drop.
Comp. Machine Type:
This menu item allows you to change the type of machines
you will be comparing yours to. When selected, a
submenu will appear next to it with the items MC68030 and
OTHERS within it. Simply, selecting MC68030 sets the
program for comparing 68030 based machines and the
OTHERS item sets the program for comparing a few other selected
machines, the A2500/20 equipped with a 14.28MHz 68020, and a
68010 equipped A2000 running at the normal 7.14MHz clock. The
default selection is for 68030 machines. Note that no matter
which machine type is selected, the one constant here is the
standard A2000. The A2000 will always be one of the comparison
machines regardless of the type selected. Do read the section
below labeled 'Alt A2000 base' however.
The current comparison machines for
each type are: (and the setting used to get the internal
figures)
68030: A2500/30--or equivalently an A2000 fitted with
an A2630 accelerator. This machine uses a 25MHz
processor. The internal comparison figures for
this machine were obtained for the following
setups: 4 megs of 100ns 32-bit RAM were used,
and the ROM image was mapped into the 32-bit RAM
area using Dave Haynie's SetCPU v1.6 program.
The exact SetCPU setting was:
SETCPU: 68030 FASTROM (INST: CACHE BURST)
(DATA: CACHE BURST).
Although on a 2500/30 the BURST setting has no
effect on the current setup.
(Can't hurt to leave it set though :-) ).
In addition, each test WAS performed with a
minimal of background tasks running...regardless
of the 'Be Selfish' option, which was used at
all times.
----------------------------------------------
A3000/25--An Amiga 3000 using a 25MHz 68030 was
used for the comparison machine in this program.
The A3000s used for the comparisons were NOT
equipped with Static-Column type FAST RAM, but
rather with standard DRAMs. I did make an analysis
of SCRAM over DRAM speed, and while there is a
difference, I felt it best to include a more or
less 'stock' type of A3000 here.
Since the ROMs are already on a 32-bit bus for
this machine, no action was (or needed to be)
taken in respect to that. For cache settings,
both the instruction and data caches were ON.
BURST mode again was not in effect due to the
system configuration.
OTHERS: 68010 Amiga: This is basically just a standard
Amiga 2000 fitted with a 68010 processor in place
of the 68000. As with the 68000 Amiga 2000, all
tests were conducted in a FAST RAM environment.
A2500/20: This is the original version of the
2500...an Amiga fitted with a 14.28MHz 68020,
and 2 megabytes of 100ns 32-bit RAM. Again,
SetCPU 1.6 was used to move the system ROM image
into the 32-bit environment.
None of the comparison machines was running any special
performance enhancing program, such as MoveSSP or VBR,
which improve performance by moving certain data from CHIP
to FAST RAM to avoid the bus contention in CHIP RAM.
Note that these programs are irrelevant for the machines using
SetCPU v1.6 to move the ROM image into 32-bit RAM. SetCPU v1.6
will perform these functions itself, and thus this does play
a factor for those machines. They were not used for the A2000
and 68010 based A2000. If you use any of these programs, on an
A2000, you may notice a slight increase in performance over the
similar machine in the comparison lineup. This increase may be
small enough, however that it will not show up definitively on
the graph or percentages, as account of the error margin.
I must make mention of the fact that for all machines used
for the internal comparisons, v1.3 of AmigaOS was used.
This INCLUDES the A3000 measurements. The reason I did
not use 2.0 is that there IS a difference in machine performance
when using v2.0 of AmigaOS. When 2.0 becomes widely available,
I intend to update the program to handle measurements for that
version of the OS. If you are using 2.0, this program will
work fine, but you cannot use the comparisons to any real
accuracy, because as of this writing, 2.0 was not burned into
ROM, and the version being used was of a RAM-based KickStart
variety. This has the effect of giving either falsly high, or
occasionally low, readings for time results and thus affects
the comparisons. [An actual ROM image will vary from a RAM
based image, due to the differences in the medium]. AIBB
will be updated, of course, and if 2.0 does come into ROM soon,
you could use this version to test the new OS's speed for
some of the comparisons which are dependent on OS functions
against 1.3 figures. Also bear in mind that the A3000 is a
very new machine, and has in fact had several components updated
over it's life so far... (including the 'Buster' RAM controller).
In fact, you should consider the A3000 results contained in
this program to be 'preliminary'...if I find that something has
changed the performance of future A3000s, I shall update AIBB
accordingly..[Also, some earlier A3000s may show slight variations
due to the above reasons].
NOTE: All machines used internally are NTSC-based machines.
PAL machines may show false performance readings for
the comparisons. In addition, overscanned displays
*MAY* have an effect on test results if they are active
at the same time the program is running. Also, the A3000
productivity mode is notorious for sucking up the system
bandwidth, so keep this in mind.
Change Base:
This menu item allows the selection of the machine to be
used as the base in the percentage comparisons. The
submenu which appears next to it allows you to choose
which machine you wish to use as the base machine...the
default being the A2000. With any base, the
percentages, and the graph show the performance of both
your machine, and the other machines as compared to the
base. The base machine will always show itself to have
a relative performance of 100% (naturally, as it's
evaluating itself against itself). The other machines
will show percentages relative to the base machine's
performance.
Large Graph Scale:
This is an option I added when it became apparent that
some of new 68040 boards to be (or have been..depending
on when you read this) released were just to fast to
fit on the normal graph scale for any test. When this
item has been selected (checked), the graph scale will
double in size...this will be apparent on the screen, as
the scale will no longer go from 0 to 14 (0-1400%), but
rather from 0 to 28 (0-2800%). Probably the only time
you would wish to do this is if your machine goes off
the scale during any test while using the standard scale.
Alt. A2000 Base:
This menu function serves a purpose which will only be
necessary for certain individuals. When evaluating the
performance of the A2000, I came across some interesting
results...Some machines ran the test SLOWER than others.
Generally, the same machines showed the slower results
on a consistant basis...so this menu function. When you
select this menu function, AIBB will use a different set of
internal comparisons for the A2000...these will reflect the
slower performance of these certain machines. If you are
running an A2000, and are within all the other parameters
used for the tests, and results are still coming up slow,
select this menu function. Now, if you are using an
accelerator, and are comparing to other machines, this setting
makes NO difference. The slower figures turn out to be a
certain factor slower than the 'normal' figures, so the net
result will be that selecting either of these will simply
end up in a 'shifting' of the other results...including your
own by the same amount. Hence, comparisons between the other
machines are not affected...it is probably a good idea to
stick with the default 'faster' results though, in order to
get an idea of how your system marks against an A2000 running
at this speed, percentage wise...and most A2000s run at this.
I've found a few that do not, and I have some ideas related to
the memory they are using, and possible the Gary chip version,
but the results for those specific machines were always slower,
wheras 'faster' machines ALWAYS showed faster, thus I have
eliminated coding errors from this phenomena.
Stack Variables:
This menu item is somewhat mislabled, but that's ok. What
this does is such: When the item is selected, (checked),
The program will use Stack-allocated variables for the Sieve
and Matrix tests. Since these tests use rather large variable
arrays, this is the reason I mentioned you must have a stack
setting of 12000 or greater in order to use this function.
The reason I included this item is that the systems do run
faster with these tests when the variables used in this way.
When the program is first started, it will look at what your
current stack setting for it is...if it is 12000 or greater,
it will invoke this menu item automatically as the default.
If you use a stack setting lower, it will use the alternate
method of test variable allocation, and ghost this menu
selection. The alternate way of variable allocation uses
memory allocation calls to reserve an area of memory for my
test variables. Because of this, it is an interesting way
to test the differences between memory speeds for different
machines (or even your own, with a few tricks :-) ). Note
that this menu item only affects the Sieve and Matrix tests.
The program will adjust its comparison figures to
the setup you have selected. NOTE: This is in no way connected
with the System Stack mentioned earlier in the System Status
menu section. The Stack being referred to here is the program
stack, which is completely seperate and is allocated when
the program's task is created upon startup. The speed
difference you will see between the two is base upon the fact
that for the external memory-allocated variables, the program
must make full address memory accesses to reference the
variables, whereas in the stack method, they are pulled off
the program stack. The difference is not great, but it is
interesting to note.
Depending on the processor your machine has, you may find another menu,
'Processor'. This field only appears if you are running a 68020 or above
and allows you to switch the caches of your processor on/off, to see the
effects doing this has on test results. The menu configures itself to
your processor type, so if you are running a 68020, the only item that will
appear under this menu is 'Switch I-Cache'. For higher processors, items
to manipulate the Data and Instruction cache, and the BURST modes will
also appear. When a cache is changed this way, the new cache status will
appear in the CPU status indication area explained below. If you do
choose to manipulate the caches during the tests, and get lazy and don't
set them back the way they were, the program will automatically set the
caches to the state they were in upon startup when you quit the program.
NOTE: As I indicated, if you are running a 68000 or 68010, this menu will
not be present, as it is of no use to those processors. (Besides, if you try
to set a Cache Control Register (CACR) value on a 68000 or 68010, neither
of which have a CACR...you get a nice, and pleasant light/sound effects
show... and associated strange happenings. :-) ) Also, although the choice
for switching BURST mode on may appear for your machine's processor, it
may have no effect. This is because your processor must be capable of
using this mode, and some are not. If you switch it on and your machine
isn't able to use it, no harm will come of it. In fact, the program will
still set the BURST enable bit(s) in the Cache Control Register, but the
processor will simply ignore them. [It'll look at what I did and say
'huh?' ;^) ].
The Screen:
The screen is divided into two areas. On the left side, you will find
the performance graph, and CPU status indications. The performance graph is
basically just a graphical display of the percentage performance of the
various machines, including your own. The scale, numbered from 0 to 14,
represents percentages in hundreds, i.e. a factor of 6 would be 600%, etc...
If for some reason your machine measures off the scale (LUCKY YOU!!!) then
the graph will not be displayed above 14 (1400%), but will stop there and
show a plus (+) sign above the graph bar. The CPU status area is directly
below the graph, and shows the CPU type in your system, and the status of
the various caches, if applicable, as well as if burst mode on the caches
has been enabled. If your CPU does not have a particular cache feature, the
display will show 'NONE'.
The right side of the display contains the numerical analysis display
boxes and the test selection gadgets. From top to bottom, the features are:
Benchmark Result: This box shows the running time in seconds for the
benchmark performed. It is not a comparison, but
simply a display of the time used in performing the
benchmark.
Base Machine = : This area will show what machine is currently being
used as the base machine for percentage calculations.
The next 4 boxes in decending order are the numerical representations of
the percentage performance of each machine for a particular benchmark.
Note that even if your machine happens to go off the graph scale, the
numerical percentage will still be shown here, so you will still get a
performance evaluation. Remember that all percentage calculations are
percentages of the base machine, where the base machine will always show
100% performance (naturally, as it is relative to itself).
The bottom portion of the right side display area contains the test selection
gadgets. A description of the test each performs is outlined below:
WritePixel: This is a derivation of the original SetAPen/WritePixel
first introduced by Computer Systems Associates (CSA).
It draws a box on the screen one pixel at a time using
the OS function call Writepixel(), then erases the box
in the same manner. The test is useful mainly for
testing the speed increase of systems which have their
KickStart images mapped into a 32-bit RAM environment.
Sieve: The Sieve test used here is the basic Sieve of
Erathosthenes test for prime numbers. It searches a
set of 8191 numbers for primes in a loop 100 iterations
in length.
Sort: The Sort test I use here is a simple shell-sort
algorithm for sorting integers. I do not use a random
list of numbers to sort, as that would result in different
benchmark times depending on the way the list turned out,
but rather I use my own 'mixing' method for scrambling
the numbers so they are mixed in the same way every time.
The test measures the time it takes to order the resultant
mess (12000 numbers).
Savage: This test is just a loop test of performing a series of
nested floating point operations on a number. This test
requires the use of the Amiga's MathTrans.library, which
should be in your libs: directory. NOTE: The performance
figures for the other machines were obtained using the
mathtrans.library which comes with the WorkBench on the
Amiga. There are versions of this library around which
map those functions and such to a math coprocessor. If
you wish to compare your machine on par with the machines
represented internally, you should NOT be using one of
these other libraries. (It would be quite an unfair
advantage :-) ). If the program cannot find the
mathtrans.library in your libs: directory, it will inform
you of the problem and disable the Savage test gadget.
Dhrystone: This one should be fairly familiar to most people. It is
a standard port of the ever-popular Dhrystone benchmark
used on so many systems. It is a close port of the original
version written in ADA by Reinhold P. Weicker, and the
Modula-2 port by Joergen Thomsen.
Matrix: A simple matrix addition/multiplication benchmark on
three 40x40 integer matrices. With a loop increment
added to smooth out fluxuations. The time in the loop
is factored out of the returned time and percentage
calculations.
Now, none of these tests has been 'optimized' in any way. Thus, you may
notice that, for instance, you get a lower dhrystone/second rating on
your machine than other programs show. This is not a problem. Since the
comparisons are done from figures recieved from this program, running this
code, the percentage differences between machines are valid, in that sense.
(A different machine will just run the code the same percentage slower, or
faster, and get a results proportional to the others). Why did I use these
'slow' unoptimized tests? Simple...if I wanted to compare compiler
efficiency, then I would want to optimize the code (for instance, the dhrystone
test will run faster using 32-bit long addressing, rather than 16-bit base
A4 register offset addressing, and using register variables could speed things
up a great deal). However, I am NOT comparing compiler/language speeds here.
The goal is to find the speed of the system relative to others. Optimizing
the code negates this goal...an optimizing compiler run can play all sorts
of neat tricks on the benchmark...entire loops can be removed if the compiler
senses they serve no purpose, etc... Doing said things is not a good way to
test system performance, so I chose to leave the tests completely unoptimized.
General Notes:
The tests performance figures here are meant to give you a general
idea of the performance of your machine. As is always with benchmarks,
there is a margin of error, and certain circumstances can increase that
margin. To get the minimum error from these tests, I recommend the
following: (Of course any of these can be disregarded if you are trying
to see the performance of your system in different environments...this is
only a general guideline to duplicate the test conditions for the machines
being compared against)
1.) Make SURE you are running in FAST RAM only. Due to bus contention,
running in CHIP or SLOW-FAST RAM (address $C00000) can cause a
reduction in performance. If the program detects it has been
loaded into CHIP or SLOW-FAST RAM, it will pop a requester up
informing you of this, but this does not tell you everything.
This requester will only appear if the MAIN program ends up
using these memory mediums. The tests themselves allocate some
memory when performed, and if you happen to get AIBB squeezed
into the last dregs of your FAST RAM, the tests themselves may
be force to use CHIP or SLOW-FAST RAM, thus degrading performance.
In general, try to be sure you have at least 50K of FAST RAM
sitting free after AIBB itself loads up. And of course, if you
are using an accelerator with 32-bit RAM, FAST RAM to you should
mean the 32-bit variety. Also a warning for 16-bit RAM: You may
have plenty of FAST RAM on your system, but there is a caveat.
You must be sure that the true FAST RAM you have is highest on
the system memory priority. Simply put, if you do not have the
1-megabyte Fat Agnus chip, that SLOW-FAST memory at location
$C00000 will end up at the same priority as your true FAST RAM,
UNLESS you have the program FastMemFirst called from your
startup-sequence. Alternatively, you can set the priority
manually with a program called MemPri. Just be sure your true
FAST RAM has priority over all other memory. This precaution
is mainly for people not running accelerators, as the memory on
accelerators is usually set up as highest priority to begin with
(and you WILL notice if it is not...)
2.) Although while using the 'Be Selfish' option all other tasks will
not be allocated CPU time, a good general rule is to try to have
as few large tasks running in the background as possible. The
reason for this is that as mentioned above the tests do allocate
memory for themselves when invoked, and if another task suddenly
eats a large portion of memory, the test may be forced to use
memory which turns out slower (CHIP, SLOW-FAST, or on 32-bit
machines 16-bit memory may end up being used). Also, if you are
doing some graphics/blitter work in the background, and run the
tests, Be Selfish may be overridden. Some graphics functions, and
most notably the blitter, can break any hold on task switching,
including a Disable() or Forbid(). In particular, if a function
makes a Wait() call, this can temporarily undo a Disable(), thus
negating a section of the benchmark run. Moreover, the data and
instruction caches on so-equipped machines are also dealing
with the code and data being used by other tasks when they are
running, so I have found the most consistant and accurate tests
come out when having as few other tasks running as possible.
Usually the internal caches don't play TOO much of a part in this,
but still for the best results possible running alone is the
best way to use this program for accuracy.
However, you CAN still get a general idea otherwise.
3.) To get the best figures, run a test more than once. The figures
will stabilize after the first test or so (as the caches on such
equipped machines end up with more of the test code than before).
This is especially true of the WritePixel and Dhrystone tests.
The Dhrystone test may continue to fluxuate slightly even after
a few tests. This is mainly due to which parts of it end up
being cached, and cannot be eliminated. The caches on 030 and
020 processors are marvelous speed enhancers, but they also make
accurate benchmarks a nightmare. The dhrystone test particularly
is a pain to get real stable figures from. It has a tendency
to have different parts of it cached during different runs, making
for slightly different results over time. Now, the fluxuation is
not tremendously great, and you will still be able to get a fairly
good CPU performance evaluation. Note however that this is one of
the reasons that you cannot take the internal evaluations here
to be 'the final word'. Also, there are some caveats
pertaining to the WritePixel test. Certain accelerators access
the Amiga's bus in different ways, and thus may show slower
(or possible faster) than another while being the opposite for
other tests. This does not necessarily mean that boards with
equivalent functions are 'defective', just that the bus access
is different, (in some cases for compatibility reasons...and
some of this is with good cause), and may show up as an APPARENT
speed difference in the WritePixel test.
In effect the WritePixel in all cases can be viewed as a speed of
ROM routine AND bus access, and not the actual speed of the ROM
image itself, as the WritePixel accesses the system bus in order
to manipulate graphics memory. This is just a fact to keep in
mind, and shows that, at least for the WritePixel test, what
shows up may not be the full story.
4.) If you are using a 68020 or 68030 equipped accelerator, you
probably know by now that in all cases you should have at least
your instruction cache turned ON. This is especially true in a
16-bit RAM environment. In a 16-bit environment, with the
instruction cache turned OFF, your system will take a SEVERE
performance hit. The reason for this is such: The 68020 and 68030
instruction unit pre-fetches are 32-bit longwords. In a 16-bit
memory situation, this is a 2 bus cycle process. In many cases,
the second 16-bit word of the pre-fetch is thrown out. In a
32-bit environment, this is not a problem...but in a 16-bit
environment, the result is fetching and then throwing out what is
then fetched again, from the 16-bit RAM environment, thus adding
another 2-bus cycle performance penalty. The 68000 does 16-bit
pre-fetches, so it does not have a problem with this. The
instruction cache on the 020 and 030 serves to 'buffer' this
pre-fetch loss in the 16-bit environment. (I explained this poorly,
but basically the idea is unless you are testing the performance
degradation of such an operation...leave the Instruction cache ON
unless you are in the 32-bit environment, and even then there
isn't any real reason to turn it off, since the Instruction cache
is read-only and does not suffer from the problems with DMA that
the 030 data cache can have (Oh...the 040 and it's full bus
snooping logic ought to fun, though...). One further thing
pertaining to 030 caches...I do know of one board (there may be
others) which does NOT use the Instruction cache while in
ANY 16-bit environment...as per the reasons above it could show
up as a major performance hit. Thus, it is best to know the
accelerator being evaluated, and exactly what it and it's caches
are doing (or capable of doing) in a given environment.
5.) The Dhrystone figures should be considered the most touchy. You
can surely get a good representation on a medium-grade scale, but
do not fine-judge anything with just one reading from this test
(or any for that matter, but this one especially). The dhrystone
test is particularly apt to give fluxuations due to cache
inconsistancies on 020 and 030 machines. (or any cache-utilizing
machine). The fluxuations are not astoundingly large, and
because of that I was able to take a weighted average and use
it for the internal comparisons between machines. (a weighted
average was taken for all internal comparison machines.).
The above tips of course (as said before) are only meant to help duplicate
the conditions used for the figures obtained for the internal comparison
machines. Now, even if you have the same type of machine as one of the
comparison machines, you still may end up with slightly different figures.
One of the major differences you may notice is an A2500/30 (or A2630)
coming up a bit slower than the internal figures for an A2500/30,
even with all the cache settings the same, is the use of faster RAM chips
(the A2500/30 or A2630 accelerator is equipped with 100ns chips running with
the processor at 3 wait states.) Now, you must remember, it will be almost
IMPOSSIBLE for you to duplicate the EXACT figures for the internal machines,
but given the exact same machine type, and settings/configuration you should
come to within a reasonable range of the comparison figures. (The reason
you cannot EXACTLY duplicate them most of the time is that no two machines
are ever exactly alike).
What you will get is basically an average mean value. This program is
mainly useful for seeing if large differences are apparent between other
types of accelerators.
This program was basically meant to check CPU performance for other
types of machines than the ones kept internally, however, you should feel
free to change your processor settings, memory area/type where the program
loads in, etc...should you happen to own one of the types of machines kept
internally. This way you can see what the different settings, and such will
do to your performance level as compared to optimum. Also, you can see
just how well your machine does against a similar machine that may have more
RAM or such, and CAN use BURST mode, provided your machine cannot, and so
on and so forth.
PROGRAMMING NOTES:
I want to make a comment on the use of Disable() within this program.
Disable() is a function designed primarily to allow a task to access data
structures shared by interrupt code, without worry of having this code
changed by an interrupt event during the access. My use of it here was
because it was the only real way to insure that my program would have the
best chance of being given total control of the procesessor. What I want
to make clear is this: If you are just starting to program the Amiga,
(or other multitasking systems for that matter), the use of Disable() or
functions like it is to be a last resort, unless you are doing something
very similar to what I have done here. Disable() is a very cruel thing
to do to a multitasking system, and should be avoided if at all possible.
There are some circumstances where it's use is necessary, to be sure, but
it should be considered that my use of it here is NOT a standard method
of usage for the call. [In fact, in most circumstances you should not
be Disable()'ed for more than 250ms, as per the RKM recommendations.]
In the context where I have used the call for this program, it won't cause
problems provided the proper (mentioned earlier) environment exists.
But to be sure, indiscriminate calls to Disable() and such are very poor
programming practice.
ACKNOWLEDGEMENTS:
I wish to thank all of the folks who helped and supported me in this
project. These individuals were all a part of the testing of this
program, and influenced it's making a great deal:
Bill Seymour: An all-around good-guy, and great help in this program's
development.
Michal Todorovic: For pointers on keeping my stack usage to a tolerable
level :-).
Michael Walters: Spotted a bug in my code early, and saved me many hours
of debugging time...
Dr. Scott Thayer: Sysop of Amiga Friends BBS, and spotter of program
quirks :-)
And of course, the beta testers who put up with my ceaseless requests for
data: Mark Manes, Dan Dwyer, Steve Curry, Bill Hagan, Aryeh Goretsky,
Tim Corcoran, Tom Thai, Stuart Logan, and Andrew Hobbs....Thanks!!!
MISCELLANEOUS:
Questions, comments, and suggestions about this program are quite welcome.
I can be reached the following ways:
Safe Harbor BBS: Amiga Hardware Special Interest Group Operator
(SIGOP--SIG Area 7) (414)548-8140
I can always be reached here.
AmiHolics BBS: (602)843-8486
Northwest Amiga Group (NAG): (503)656-7393
Amazing Connection BBS: (602)843-6574
Amiga Friends BBS: (714)870-4754
JDR Microsystems BBS: (408)559-0253
Miller's Amiga System BBS: (612)698-1485
I can also be found on Usenet: lkoop@crash!pnet01.cts.com (Internet)
[pick your path :-)]
and have been known to lurk around IntelecNet.
If you wish, you can also contact me via the U.S. Mail service at
LaMonte Koop
565 Park Meadows Dr. #302
Waite Park, MN 56387
About me...Well, I'm a near-fourth (A what?) year university student
majoring in Electrical/Computer Engineering, Physics, and Mathematics.
Why all three? Why not...they're all fairly related, and I find them
hard to choose between. AIBB is the result of my fascination with both
FAST computers, and the hardware that makes them...and everyone needs a
hobby. I just happened to pick evaluation of accelerators for mine :-).
If you have some interesting ideas for a project, let me know. I'm always
looking for something to do :-). If it's not within my current capabilities,
I will probably try to make it so. (Or yell AAARRRRRRGGGGHHHH really loud
and mutter strange things :-) ).
[Anybody ever thought of using the MMU as a memory defragmenting tool?...
...mmm, just a thought.]