Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uunet!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <10630.tnews@templar.actrix.gen.nz>
Date: 23 Jan 91 01:37:29 GMT
References: <1991Jan14.221532.4431@cunixf.cc.columbia.edu> <11719@goofy.Apple.COM> <1991Jan16.061456.15340@zorch.SF-Bay.ORG> <1991Jan16.174416.16308@cunixf.cc.columbia.edu> <1991Jan18.231330.16290@Neon.Stanford.EDU> <7553@sugar.hackercorp.com> <1991Jan21. <1991Jan21.
Organization: TAP, NZAmigaUG.
Lines: 52

Quoted from <1991Jan21.132909.18488@ncsuvx.ncsu.edu> by kdarling@hobbes.ncsu.edu (Kevin Darling):
> In <1991Jan21.004720.25985@ncsuvx.ncsu.edu> I contend:
> >> So the speed diff is only related to the (Mac GetEvent delay x number of
> >> times) it's called; versus the (Amiga tick routine delay x number of times)
> >> it's done.  Unless we know those timings, speed claims are meaningless.
> 
> >jbickers@templar.actrix.gen.nz (John Bickers) replies:
> > Having the ray tracer do one of these GetEvent() calls must have
> > more of a relative effect on the ray tracer than having another
> > task in the wait list under Exec.
> 
> "Must have"?  Again, without timing data such statements are meaningless
> conjecture.  If say, the GetEvent() took 10us to figure out there was no
> events/tasks, and the regular Amiga tick interrupt routine took 20us,

    This is somewhat askew... I said "more of a relative effect". By this
    I mean:

    Suppose the Mac tracer rendered a scene in N seconds if it didn't
    call GetEvent() every so often. Adding GetEvent() calls must
    increase the rendering time (unless someone's finally gotten
    those thiotimoline (sp?) chips working :).

    Now suppose the Amiga tracer rendered a scene in N seconds with M
    idle tasks on the machine. Adding another task to do what the
    GetEvent() call was supposed to accomplish (user interface stuff)
    has the same cost as adding any other task - whether it's connected
    with the tracer or not. So the "relative" affect is zero - the
    extra interface has the same cost as any other task sitting idle.

    The Amiga N may be greater than the Mac N, and adding a task may
    increase the Amiga N more than adding GetEvent()s increases the
    Mac N, but this extra cost isn't "the tracer", it's the same as
    adding any other task.

    (On a related note, you can simply boost the tracer's priority as
    required to reduce the M value above).

> I fully agree!  At the same time, we just didn't have enough info to make
> a claim that preemptive = faster in the given example. In fact, I'd bet that

    Yeah. Multitasking at all implies some overhead that a single-tasking
    system isn't going to have. This is the price we pay for convenience.

    Xoper reports figures that look really bad re CPU usage during
    CPU intensive things. Anyone know how accurate Xoper can be assumed
    to be?

> That kind of kneejerk reaction can make all claims suspect.  best - kev
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***