Path: utzoo!attcan!uunet!snorkelwacker!apple!usc!cs.utexas.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: stopping multitasking
Message-ID: <14698@cbmvax.commodore.com>
Date: 27 Sep 90 19:44:20 GMT
References: <4440@crash.cts.com> <14575@cbmvax.commodore.com>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 26

In article <14575@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes:
>In article <4440@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
>> however, if BOTH forbid() and disable() [I just wanted to see the effect]
>> are called, some tests (particularly a version of the WritePixel test first
>> introduced by CSA) are FASTER, whilst others (my Sieve test) are SLOWER than
>> with just one of the calls made....and not by jsut tiny amounts...by a
>> second or so. [other tests differ in performance by smaller amounts].
>
>A second *is* a tiny amount. One thing that I must point out is that while
>Disable() allows your program to run uninterrupted, the Enable() call might
>take a long time to execute, relatively speaking. Thus for quick benchmarks
>(smaller than 10 seconds), they useage of Forbid()/Disable() might affect
>the performance apparently randomly.

	A more important point: various system calls, including some graphics
calls, will Wait() for things to complete.  This breaks Forbid() AND Disable().
This could cause unexpected results.

	I would advise against disabling interrupts for all but pure CPU
benchmarks, and probably against disabling multitasking in most benchmarks.
You're measuring system performance on a task, not processor speed.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"