From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
Newsgroups: comp.sys.next.advocacy
Subject: Re:  NeXT's, Amiga's, PC's, MAC'S, (was Re: Question #2 "Are Macintosh Users Really Happy?")
Distribution: world
Date: 6 Sep 92 17:21:15 PST
Organization: Not an Organization

>In article <timm.715222975@void> timm@void.ncsa.uiuc.edu (Tim McClarren) writes:
>>mmelling@Trirex.com(Michael Mellinger) writes:
>>..
>>What does asynhronous have to do with anything?  If you figure that that
>>Amiga blitter is equivalent to a 68030 in processing speed (CPUBLT is
>>faster on a 68030 for many blits) then you have 2x68030 is processing
>>speed on an A3000.  A 68040 is 3x68030 in integer performance.  In other
>>words, the 25MHz 68040 NeXT is capable of doing more work in 1 second than
>>the Amiga.  If you figure that a 80586 clone running NeXTstep or 88110
>>RISC NeXT will be at least 3 times faster than the current NeXTstation,
>>then it looks like animation will be much nicer on the next generation of
>>NeXT computers.
>
>Hmm...I haven't really been following this thread very closely, but
>I noticed this post.  Asynchronous may have a lot to do with animation.
>Anyways, equating the Amiga blitter with a 68030 is dangerous at best.

    Here's a question for you:

    Is one processor at full speed equivalent to two processors at half
    speed?

    For straight linear calculations one processor beats ass, but for
    interactive operations (servicing of interrupts) and synchronous
    message traffic (user application <-> window server) two processors
    yield much better REAL TIME / INTERACTIVE performance.

    With two processors, context switch overhead for message traffic
    between two processes generally goes away (it simply doesn't occur)...
    and context switch overhead is a big hit on single-processor machines.
    I dunno if the NeXT takes advantage of Mach's ability to use busy-wait
    locks when more then one processor is installed.

    The sequent is probably the best example of all of this... 16 80486
    processors. When an interrupt occurs it is dispatched to an unloaded
    processor by hardware.  Interrupt latency is 16 times LESS (or better)
    then if you had one processor going at 16x... it may not seem that way
    since the total in-interrupt time is exactly the same, but the critical
    path for an interrupt is on entry to the interrupt routine, not the
    body of the interrupt routine.

    Say you get 16 serial interrupts (16 serial ports).  With one processor
    you have to process the 16 interrupts sequentially so some interrupts
    have to wait for the BODY of previous interrupt service routines to
    completely finish before they get a chance.  With 16 processors each
    processor takes one of the interrupts simultaniously, therefore no
    interrupt will have to wait for the entire body of previous interrupts
    to finish processing, they all get serviced within microseconds.

    The same sort of thing goes for synchronous message traffic between two
    processes.	Not only do context switches go away, but much of the
    overhead of constructing+sending and receiving the message is pipelined
    yielding the same or better performance then a single processor could
    do.

    In anycase, the moral of the story is:  No matter how slow your
    coprocessors are they will make a huge impact on machine performance by
    removing, not only the nominal overhead of the operation, but also the
    overhead associated with the TWO context switches that a single
    processor would otherwise have to perform.

					-Matt

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708     ham: KC6LVW (no mail drop)
    USA

Newsgroups: comp.sys.next.advocacy