lkoop@pnet01.cts.com (Lamonte Koop) (09/17/90)
I have a question relating to the use of the system call Forbid() and
Disable()...I am currently writing a benchmarking program which implements
several common benchmarks used to time system performance (complete with full
intuition interface!)...ok, here's the question: I have an option in the
program's menu to enable a user to disable the multitaking in the system to
get more accurate timing results...unfortunately, I've discovered some, shall
I say interesting, things about both forbid() and disable(). If the program
uses just forbid(), the timing results for certain tests are slower than if
just disable() is called...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]. I know the confusion I have here is based on a
misunderstanding of these functions, so could someone kindly give me a clue as
to what's up here? Also, what would be the best function of these two to use
for the most accurate results?
Thanks in advance:
---LaMonte
"The most original .sig file yet...a non-existant one..."
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
ARPA: crash!pnet01!lkoop@nosc.mil
INET: lkoop@pnet01.cts.comgriffith@eecs.cs.pdx.edu (Michael Griffith) (09/18/90)
lkoop@pnet01.cts.com (Lamonte Koop) writes: >I have a question relating to the use of the system call Forbid() and >Disable()...I am currently writing a benchmarking program which implements [rest deleted]... >smaller amounts]. I know the confusion I have here is based on a >misunderstanding of these functions, so could someone kindly give me a clue as >to what's up here? Also, what would be the best function of these two to use >for the most accurate results? >Thanks in advance: >---LaMonte Well the functions Forbid() and Disable() were not meant to be called together. Forbid() disables the task-switching mechanism of the Amiga OS, thus ensuring that your task is the only one running, however it does not disable interrupts. Disable() also disables task-switching plus the interrupts. Since Disable()ing is hazardous over long (read long relative to instruction execution speed) amounts of time due to problems like over flowing buffers, etc., I believe you will find Forbid() to be your most likely choice. Forbid() should tend to run slower, but is safer. In most cases, Disable() is only needed when accessing data structures that may be modified or read by interrupt routines. | Michael Griffith | If I had an opinion it certainly | | griffith@eecs.ee.pdx.edu | wouldn't be the same one as | | ...!tektronix!psueea!eecs!griffith | Portland State University anyways. |
valentin@cbmvax.commodore.com (Valentin Pepelea) (09/21/90)
In article <4440@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: > > I have a question relating to the use of the system call Forbid() and > Disable()... I am currently writing a benchmarking program which implements > several common benchmarks used to time system performance > If the program uses just forbid(), the timing results for certain tests are > slower than if just disable() is called... This is normal. Forbid() allows interrupts to be processed, therefore some of the time lost is because it is taken away by the interrupts. > 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. Another thing to point out is that the timer device might not accurately measure the time, particularly when long Disable()s are in effect. Better run your benchmarks in a loop, an time them with a wrist watch rather than the Amiga's internal clock. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
jesup@cbmvax.commodore.com (Randell Jesup) (09/28/90)
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!"