Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@texnext.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Low End NeXTs (was Re: Desktop publishing) Message-ID: Date: 5 Apr 91 17:32:50 GMT References: <14483@life.ai.mit.edu> <4753@lectroid.sw.stratus.com><34936@athertn.Atherton.COM> <1991Apr3.220544.22348@cs.ubc.ca> Organization: Gustavus Adolphus College Lines: 70 Nntp-Posting-Host: texnext.gac.edu In-reply-to: sritchie@cs.ubc.ca's message of 3 Apr 91 22:05:44 GMTLines: 70 In article <1991Apr3.220544.22348@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: In article <34936@athertn.Atherton.COM> dlw@Atherton.COM (David Williams) writes: >NO! Leave the networking in. Just take the NeXTStation pizza box and >use the 030/25 setup[cpu/fpu/dsp] in and sell for $2495. NeXT's [...stuff deleted...] >David Williams I wonder if 68030 + 68882 costs more than a 68040? Not yet, but it will be there by the time NeXT could come out with a new '030 machine . . . Some potential garbage not necessarily related to David's posting: Maybe the real trick in getting usable MIPS is multiprocessing. Sure, 56 MIPS sounds great, but don't forget that your cache gets destroyed at interrupt time, thus reducing 56 MIPS to DRAM speed. Well, OK, I don't know what I'm talking about, but maybe there is some truth to that statement. Actually, it's worse than that. That 56 MIPs for the HP PA is more than likely closer to peek MIPs than HP would like to admit. Which means that the actual performance on real applications will be less. The IBM RS/6000 suffers from this problem - the performance improvement you'll see on real applications is not in line with the quoted 40,000 MIPs . . . Hell, take a look at networking. Even 15 MIPS isn't enough to drive TCP at Ethernet rates in the Unix environment. This is one area that could use some dedicated multiprocessor support. This is the way to go, IMHO. Take a look at the PC world - graphics cards with TI 34010 or other dedicated coprocessors are a commodity item. Let's throw an i860 (no, wait, a i960) on the motherboard with some RAM, and get rid of that DPS overhead. Give it to me in monochrome (8-bit mono on an i860 would be sweet) and I'll buy as many of those machines as I have the money for . . . About BlastApp: great game. Highly addictive. But one thing that worries me is this. I remember reading a disclaimer somewhere saying that the game may suffer performance problems on a 030 machine. I'm really worried about this. Even with a tiny window like BlastApp has, is DPS really that much of a bottleneck? Or were there some efficiency compromises made by the implementor? Where does the real bottleneck lie? Don't get me wrong, I'm not complaining. I really like the stuff that can be done with Display PostScript, and I've taken advantage of this power in my own applications. To see what DPS can do, take a look at Stuart (no pun intended, Stuart!). DPS gives a much larger window of performance possibilities than many other windowing systems, such as X or QuickDraw. The problem is that it's so damn flexible. What it comes down to, though, is that there can be a great return on investment for those willing to spend some time and elbow grease looking at the DPS code that they output. Unless you're quite lucky (or experienced), your first attempt program will be 2-5x slower than one that's been more well-thought-out. This is part of the reason I think all developers should be forced to work on '030 machines, as that gives them more incentive to think things out . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Simply press Control-right-Shift while click-dragging the mouse . . ." "I smoke the nose Lucifer . . . Banana, banana."