Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!actrix!templar!jbickers
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Computer Architecture question
Message-ID: <3496.tnews@templar.actrix.gen.nz>
From: jbickers@templar.actrix.gen.nz (John Bickers)
Date: Sat, 10 May 1991 06:50:24 GMT
References: <y_4G=zw&1@cs.psu.edu> <3310.tnews@templar.actrix.gen.nz> <1991May9.070349.15151@neon.Stanford.EDU>
Organization: TAP, NZAmigaUG.
Lines: 26

Quoted from <1991May9.070349.15151@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie):
> jbickers@templar.actrix.gen.nz (John Bickers) writes:

> >    Who knows, who cares. Use the thing as a co-processor, like they

>   This generally works OK for special purpose jobs, but not very well for
> general purpose work, i.e. you'd like your OS to also go fast, but it
> can't because its running on the host processor.

    Ok. Shouldn't the OS on the host processor already be running at an
    acceptable rate for the system to make it out the door in the 1st
    place, though?

    Speedwise, it's going to be better to have part of a system on one
    fast chip and another on another faster chip, than it is to just
    have the faster chip. Like the 68030 + Blitter is better than just
    a 68030, even though the 68030 can outperfrom the Blitter in most
    (all?) cases.

    And for tasks where speed == real money, this could be important.
    The important tasks will very probably be special purpose ones.

> Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Endless variations, make it all seem new" - Devo.          ***