Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!stanford.edu!neon.Stanford.EDU!torrie From: torrie@cs.stanford.edu (Evan Torrie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Computer Architecture question Message-ID: <1991May10.182934.28724@neon.Stanford.EDU> Date: 10 May 91 18:29:34 GMT References: <3310.tnews@templar.actrix.gen.nz> <1991May9.070349.15151@neon.Stanford.EDU> <3496.tnews@templar.actrix.gen.nz> Sender: torrie@neon.Stanford.EDU (Evan James Torrie) Organization: Computer Science Department, Stanford University, Ca , USA Lines: 64 jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May9.070349.15151@neon.Stanford.EDU> by torrie@cs.stanford.ed >> 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? Yes, but most people (myself included) would like to see a significant improvement when you plug in a 3x faster processor. If you can only utilise that faster processor on say 10% of your workload, you get a miniscule 1.07x speedup. If you could utilise the 3x faster processor on your entire workload, you get a 3x speedup. The problem as I see it with Transputers and the like, is that everyone is just using them as coprocessors for some of their compute bound tasks. Now, if you had a real parallel OS with a parallel development system, and an installed base of parallel applications, they might make more sense for the general microcomputer user. Unfortunately, we don't, and we're unlikely to have such a PC system for quite a while. In terms of cost/performance, I would far rather have a single faster CPU running the whole operating system, than both a slow CPU doing 80% of the work, and the faster CPU doing 20% of the work. > 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. Actually, there are many examples of parallel computer applications, where the application is slower on multiple processors than it is on a single processor (because of the communication overhead). This usually requires a reworking of the algorithm - something which is still a hot topic in the research world. > And for tasks where speed == real money, this could be important. > The important tasks will very probably be special purpose ones. Yes, but we were talking about the general microcomputer user, where the two possibilities were 1. Replace the 68040 with an 88110 for a 3x performance increase (Mike's suggestion) or 2. Add on a few transputers on a card (with potentially 10x performance increase) to an existing 68040. (your suggestion). In terms of cost/performance given the current operating systems, and state of parallel program development, option 1 is infinitely more preferable for Trev Dagg. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860