[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GS Speed test



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?

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

Thanks

Andrew