jbickers@templar.actrix.gen.nz (John Bickers) (05/08/91)
Quoted from <y_4G=zw&1@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > Can you just drop a 68040 into any computer and expect it to be as > fast as a computer designed around the 68040? Now, can you just drop No, but try dropping a 68040 into a _well-designed_ computer and it may well do better than a computer that was _poorly-designed_ around the 68040. > an 88K processor in a computer that is based on the 68K and expect it Who knows, who cares. Use the thing as a co-processor, like they use those Inmos chips. > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
torrie@cs.stanford.edu (Evan Torrie) (05/09/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >> an 88K processor in a computer that is based on the 68K and expect it > Who knows, who cares. Use the thing as a co-processor, like they > use those Inmos chips. 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. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Lay me place and bake me pie, I'm starving for me gravy... Leave my shoes and door unlocked, I might just slip away - hey - just for the day."
jbickers@templar.actrix.gen.nz (John Bickers) (05/10/91)
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. ***
torrie@cs.stanford.edu (Evan Torrie) (05/11/91)
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
jbickers@templar.actrix.gen.nz (John Bickers) (05/11/91)
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. ***