[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II benchmarking software?
- Subject: Re: Apple II benchmarking software?
- From: mjmahon@aol.com (Michael J. Mahon)
- Date: 21 Oct 2003 17:15:39 GMT
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <1s9lb.46797$mp1.4368@nwrddc02.gnilink.net>
- Xref: archiver1.google.com comp.sys.apple2:522
Frank Townsend asked:
>Other than timing for-next loops and so forth, was any software ever written
>to compare Apple II performance?
To my knowledge, nothing more than simple loops were ever written
for the purpose of testing performance.
>I'm replacing my Transwarp GS 8k cache with a 32k cache and would like to
>see to what degree performance improves.
As you probably know, the performance effects of a larger cache
are strongly dependent on the speed of the processor when runnng
from cache, the size of the cache, the organization of the cache, and,
of course, the code and data locality of the program being run.
A good benchmark program written for the purpose should be able
to determine the first three factors by varying parameters to change
its locality in predicatable ways.
One reason that performance benchmarking was never a big thing
on Apple II's is that there was never really any standard way
to determine elapsed time, so such a program would have to rely
on the user's elapsed time measurements for results.
In this particular case, replacing an 8KB combined, direct-mapped
cache with a 32KB cache, you could see anything ranging from no
increase in speed (if your test program is essentially cache-resident
in the 8KB cache) to the full speed ratio of the accelerated clock to
the unaccelerated clock (1MHz) if the test program is pathologically
thrashing in the 8KB cache, but nestles nicely in the 32KB cache.
Your actual results, of course, will be somewhere in between. ;-)
Even large programs often spend a very large fraction of their time
in a few relatively small loops. The code for these loops can often
be easily mapped by a direct-mapped cache. Whether the data
can be so mapped depends strongly on its organization and usage
patterns. Interpreted programs (like Applesoft) can be big winners,
since the interpreter code is compact and the data (the Applesoft
program and its data) often are, too.
A fundamental property of caches is that their advantages are
completely dependent on the statistical nature of the address
reference patterns, so it's hard to make any blanket statement
about how they will help any particular program without knowing
exactly what its address traces are.
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/