Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 2.0 Slowness???
Message-ID: <16002@cbmvax.commodore.com>
Date: 21 Nov 90 09:17:52 GMT
References: <5748@crash.cts.com> <15987@cbmvax.commodore.com> <1990Nov20.233747.16565@cunixf.cc.columbia.edu>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 23

In article <1990Nov20.233747.16565@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes:
>	I ran dhrystones using Forbid(), so other tasks should be
>irrelevant. On my 3000 I got a difference of 120 dhrystones/sec
>between 1.3 and 2.0.

	Not neccesarily.  It depends on what interrupt services they
register with (for example, vblank, or timers, etc.)  Also, for such
a small difference (relative to timing quantums), it could just be a more
complex vblank handler (which is what handles hedley screens, etc - even
if not active, it has to check if they are).  Video setups might be different -
the amount of overscan, screen position, etc, etc, etc.  Timer device
could be returning more accurate values under 2.0, or maybe it has a bit
more overhead.

	If you want to really test JUST the processor, turn off interrupts, 
turn off sprites and the screen, and use a CIA timer directly (since 
timer device can affect you).

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Thus spake the Master Ninjei: "If your application does not run correctly,
do not blame the operating system."  (From "The Zen of Programming")  ;-)