Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!templar!jbickers From: jbickers@templar.actrix.gen.nz (John Bickers) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Computer Architecture question Message-ID: <3631.tnews@templar.actrix.gen.nz> Date: 11 May 91 14:39:02 GMT References: <3310.tnews@templar.actrix.gen.nz> <1991May9.070349.15151@neon.Stanford.EDU> <3496.tnews@templar.actrix.gen.nz> <1991May10.182934.28724@neon.Stanford.EDU> Organization: TAP, NZAmigaUG. Lines: 62 Quoted from <1991May10.182934.28724@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > significant improvement when you plug in a 3x faster processor. If > you can only utilise that faster processor on say 10% of your Sure it's nice... > 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 The best we can do, at the moment... > 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. Who shouldn't be having problems with the speed of a 68040, unless they have a funny OS (or a slow HD)... It just seems to me that if the base CPU is a 68040, then any extra speed you want to squeeze out of the thing (remembering that faster CPUs in a single processor system are going to be tied back to their IO) is going to be special purpose. > 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. But if that 80% consisted primarily of processing user input, or other relatively slow IO bound things like OS stuff is? There are pros and cons to the cost/performance thing. In terms of performance/performance however, adding coprocessors comes out on top. > 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. Sure. Adding faster chips as full coprocessing CPUs is part of the OSes of the future, no doubt. > 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. On the other hand, for people whose compute-bound stuff IS usually special purpose (like myself - if I had a set of transputers, I'd use them), and the rest of whose operations are easily handled by a 68030, option 2 is preferable. I think there are parallels here between this and folks who speed up their MS-DOS PClones by replacing 80286s with 80386s at higher MHz, as opposed to those who get improvements by changing platforms. Different user requirements, different attitudes to problem solving. > 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. ***