Re: GS Speed test

[mjmahon@aol.com (Michael J. Mahon)]

Andrew Webber replied:

>mjmahon@aol.com (Michael J. Mahon) wrote in message
>news:<20020624004836.23816.00000576@mb-dh.aol.com>...
>> Wayne Stewart wrote:
>> 
>> >"Michael J. Mahon" wrote:
>> >> 
>> >> Andrew Webber asked:
>> >> 
>> >> >Is there any program that will benchmark a GS? I want to compare some
>> >> >ZIP configurations, and would like to rely on a program rather that my
>> >> >stop watch :-)
>> >> 
>> >> Ah, benchmarking...
>> >> 
>> >> If you just want to know what the max speed is, check the processor
>> >> clock frequency.
>> >> 
>> >> But if you want to know how much faster it will do some task that
>> >> you care about, you're pretty much in stopwatch territory.  In principle
>> >> it would be possible to use the internal IIgs clock to automatically
>> >> time an application, but since most applications you would care about
>> >> are interactive and don't run from an EXEC file, automating the clock
>> >> reading isn't worth the trouble.
>> >> 
>> >> -michael
>> >
>> >I couldn't think of any way to benchmark my IIgs when I was upgrading.
>> >I ended up using a stopwatch. I timed a shift boot which I didn't
>> >consider 
>> >too accurate since the duration of the boot was so short. I also tried 
>> >converting a huge AppleWorks 3 over to AWGS(I think it was about 850k). 
>> >Not scientific but I wanted to get a feel as to how larger cache at
>> >lower 
>> >speed would compare with a smaller cache and more mhz. At the time when 
>> >I was buying accelerators the choices available seemed to be 7mhz32k 
>> >cache and 8mhz16k cache.
>> 
>> Yes, such measurements are notoriously difficult to make meaningful,
>> which is why the best measure is some task that you do frequently that
>> you hoped to accelerate--say, a compile.
>> 
>> Each application will have a different hit ratio in the cache, a different
>> memory read to memory write ratio (writes are unaccelerated), and a
>> different sized "footprint", so the actual speedup of a cached system is
>> quite dependent on the application, and even on the data set.  Effective
>> speed can vary all the way from no speedup at all, to nearly the maximum
>> speedup.
>> 
>> And, of course, I/O is seldom accelerated, since the device data rates
>> are unchanged.  So to the degree that a program is I/O bound, it will not
>> see much benefit from acceleration.
>> 
>> The 8MHz Zip Chip for the 8-bit Apples can, under the most favorable
>> conditions, speed up a 1MHz Apple eightfold, but I note that it typically
>> speeds up an Applesoft program by about 5x, with no I/O.
>> 
>> Stop watch timing should, with practice, be repeatable within 0.1 second,
>> so anything that takes at least 10 seconds will be timed to within 1%.
>> That seems good enough for "government work".  ;-)
>
>That is what I ended up doing. I was initially using the demo of Out
>of this World to see if I noticed a speed improved when modifying my
>ZIPGS between 8Mhz/16K to 12Mhz/32K and basically I did not see much
>improvement.
>
>I then decided to try decompressing a SDK file to a 800K RAM drive,
>this proved quite interesting. I got the following:-
>
>Test :- Decompress Megademo disk 1 to 800K RAM drive
>
>8/32 = 44Secs
>10/32 = 38Secs
>12.5/32 = 32Secs
>
>This was good as it proved that the changes I were performing actually
>were providing a performance increase. I worked out that I got a 28%
>increase between 8 to 12.5 Mhz. Does this seem ok?

So a 25% accelerated clock speed increase delivers about a 16% increase
in application performance.  This means that about 2/3 of the computation
the application does is accelerated, while 1/3 is not.

Normally, we would expect the speed improvement to "level out" as the
accelerated speed increases, since the time required for the non-accelerated
part of the computation will not decrease, and will eventually dominate the
total running time.  For example, if the processor were infinitely fast on the
parts where it could run out of cache, then the total time for the application
would be just the time required by the non-accelerated part.

These results seem very reasonable.

-michael

Check out 8-bit Apple sound that will amaze you on my
Home page:  http://members.aol.com/MJMahon/