Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@erick.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: RISC, CISC, and MULTIPROCESSORS Message-ID: Date: 15 May 91 18:10:23 GMT References: <19229@sdcc6.ucsd.edu> Organization: Gustavus Adolphus College Lines: 80 Nntp-Posting-Host: erick.gac.edu In-reply-to: ph600fbj@sdcc14.ucsd.edu's message of 10 May 91 06:36:49 GMTLines: 80 In article <19229@sdcc6.ucsd.edu> ph600fbj@sdcc14.ucsd.edu (james dehnert) writes: It has occured to me after reading the post on how to put your 030 board in your 040 cube and make it run post that perhaps NeXT could make a multiprocessor board to boost preformance on the cubes. Imagine a board that you could put 1 to 4 68040 ( or even 88110 ) chips on right in next to your 030/040 motherboard. The Mach kernel can handel this ( can't it? ). I'm sure you would need quite a bit of memory to get it to work really well, but I'm convinced that MY cube isn't going to run the way I want it to until i get at least 40 meg of RAM ( not that I am unhappy now, but I do love speed ) I'd say get the extra memory. The problem with doing a multi-processing cube is that in many cases, it simply would not increase the speed. Without some fairly radical restructuring of how the programs on the NeXT work, at least. What parallel processing would do is allow people to do multiple disjoint things at once. _But_ the main speed complaints I've found people have with the NeXT aren't related to how much they get done once they've started doing it - it's how long it takes to stop doing one thing and start doing another. This can be seen by going out and grabbing either the Monitor program, or my TimeMon program. Let it run for awhile while doing normal things, and you can see how much the processor's being used (better with Monitor, I'll admit). Basically, the processor is used a whole bunch when you switch between programs, and not alot once you're in a program. For instance, right now typing into a Stuart session, % CPU time being used is lingering around about 10%. Similar results with Edit. I think the main difference is that what is really needed is a way to lower the _latency_ (time from when the user initiates an action to when feedback occurs), rather than the bandwidth. With the current structure of the NeXT (and Unix in general), parallel processing gives mainly high-bandwidth. To restructure things so that it can also give better latency will to some extent cripple the performance on non-parallel machines. Back to the memory. As I was talking to someone at the MN NeXT user's group meeting, it was mentioned that they were a little afraid of buying a NextStation, as they expected a RISC or faster '040 offering to be coming up. I don't think this is so much of a problem. Our experience with '040 upgrades is that upgrading the computer does not improve perceived performance so much as upgrading the memory. A 16M '030 system will often feel almost as fast or faster than an 8M '040 system, especially in a heavily NFS-mounted network like ours. The reason, of course, is that the biggest thing people notice is the time between starting actions and when they are finished. For most actions on the NeXT, this doesn't require all that much processing power - unless you need to bring the OS in and swap some pages to the swapfile. On a 16M system, you can reasonably run a couple NextStep programs almost entirely in memory, while on an 8M system, you can barely run one. I feel fairly strongly that I'd rather have a 16M or 32M 25Mhz '040 than an 8M 40Mhz '040. Lastly, some disclaimers. For those of you doing stuff like image processing, or large Mathematica calculations, or speech processing, or AI work - yes, the fast machine will make a difference. That's because you've got lots of stuff to keep it busy with. Same with parallel machines - you can find stuff to keep the extra processors busy. What I'm aiming for is the sort of generic user. These are users using the machine for programming, or desk-top-publishing, word processing, etc. (This would basically be myself, when you get down to it.) For these people, more memory is the big constraint, a faster processor will come second, and multiple processors will run third. This will probably change as we come across more and more ideas about how UIs should work, and how operating systems are structured, but for now, we're a bit stuck. Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad