Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.arch Subject: Re: Single/Multi Tasking position summary (was Re: Single tasking) Message-ID: <18079@bu-cs.BU.EDU> Date: 30 Dec 87 04:38:36 GMT References: <60@amelia.nas.nasa.gov> Organization: Boston U. Comp. Sci. Lines: 76 In-reply-to: fouts@orville.nas.nasa.gov's message of 29 Dec 87 18:16:25 GMT Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) From: fouts@orville.nas.nasa.gov (Marty Fouts) >He has also raised another example of parallel processing >enthusiasm which I try to counter when I can. He shows that an Encore >Multimax gives a speed of of 50x over a 750 for a particular make. Of >course, this looks good until you realize that he's talking about two >different generations of processors in two different price ranges. I >would be interested if Barry would tell us the speedup the Multimax >gets over doing the same make on 1 of its cpus. I would also be >interested in comparing the Multimax performance to that of a single >processor system done in more recent technology than an 750, for >instance a Sun 3/260. Sure, glad to (would you believe first there was a problem with tmp on the Sun, then the copy on the encore someone had, um, patched so I had to revert the code to its original state as it wouldn't compile at all, then I got everything going and kicked the plug out of my terminal when I got up to empty the washer...no kidding...arghhhh! How do I benchmark my LIFE!) The software in question was nethack which has 75 .c modules, approximate wall clock time to compile (that's the third number which csh reports when you say 'time make', after user and system, I prefer wall clock time as I don't pay for the cycles, I pay for employee time and with my own boredom, I can get into that argument if you want, other measures aren't useless, I just consider this the most important for something like compilation.): System h:mm:ss Notes Vax11/750: 1:39:00 (4.3bsd, 8MB, RA81s) Encore/Umax: 2:10 (6 CPUS, make told to use at most 8 processes*) Encore/Umax: 11:00 (same machine, use at most 1 process) Sun3/280: 13:32 (16MB, Super-eagles, 68881) Machines all lightly loaded or unloaded (the 750 was unloaded tho it's hard to gauge how much the little thing is bothered by net traffic, there were a few users on the Encore playing games etc, the Sun3/280 might have been doing a little file serving tho it didn't look like anyone was around, certainly some mail was processed during the make as it's the campus mail server but the University is closed for the week and it's 11PM so that should be nominal, I could check the syslog I guess.) In short, most machines were as good or better than when I usually use them, it might not be rarified, but it's certainly realistic (another argument about what I call Christmas eve benchmarks as in "sure the 3090 does 40MIPs, I can get that on Christmas eve, any other time it has 200 users and seems slow and no one's giving me my own 3090".) Beyond that (this is too long already) I do agree with Marty and also agree that I may have misunderstood/misrepresented what he was saying. It's hard to tell exactly which applications will get exactly what speed up. I do believe with general purpose parallel machines such as the Encore or Sequent (as opposed to special purpose machines which seem to put the entire burden on the coder to get any parallelism) one might be able to get enough advantage in price/performance to justify the machine itself. At that point they can explore how they can further exploit the new tool (as apparently both of us are.) Unless you're (this is the general audience "you") convinced that there's no possibility of there being anything in it for you I can't think of any other way to explore the potential without actually using one. This doesn't mean it's for everyone (tho I could argue that the general purpose models are very good at some very mundane problems, perhaps even more accessible than with exotic problems) but I am glad to have the opportunity to have gained relatively early access to this technology (again, general purpose parallel processors.) -Barry Shein, Boston University * I use slightly more processes than CPUs on makes because I find the performance continues to improve a little beyond NPROCS=NCPUS. I assume this is due to some processes always being in I/O wait. See all the neat things about parallelism we can begin to form intuitions about, if we explore it.