lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (10/16/89)
In article <130800001@peg> robert@peg.UUCP writes: >Why should we welcome a continual increase in MIPS (VUPS or whatever)? >We have enough trouble designing programs which work without error at the >moment. These will just get to the error state faster with more power. Well. Speaking as someone who has spent a lot of his life finding other people's bugs: I disagree completely. More mips didn't just take us from slow to fast. It also took us into new worlds. Compare a MacIntosh to a hardcopy terminal that timeshares BASIC from a PDP-8. Speed means that the human is catered to. I don't see that this has come to an end, either. Further, real experience says that I'd rather debug on a fast machine than a slow one, all else being equal. I hate waiting minutes for breakpoints to hit: I hate waiting overnight for rebuilds: I hate waiting days for test suites to complete. Heck, in the old days, we didn't HAVE much in the way of test suites - it took too long to run them, and it took too long to develop "unessential" code on @#$%^& batch machines. Besides, speed allows us luxuries like coverage tools. About the only hardware feature I used to pray for was "breakpoint at data address". It turns out that there are several ways to do this on conventional hardware. -- Don D.C.Lindsay Carnegie Mellon Computer Science
colwell@mfci.UUCP (Robert Colwell) (10/17/89)
In article <6535@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >In article <130800001@peg> robert@peg.UUCP writes: >>Why should we welcome a continual increase in MIPS (VUPS or whatever)? >>We have enough trouble designing programs which work without error at the >>moment. These will just get to the error state faster with more power. ... >Well. Speaking as someone who has spent a lot of his life finding >other people's bugs: I disagree completely. ... >Further, real experience says that I'd rather debug on a fast machine >than a slow one, all else being equal. Agreed, as far as that goes. We've hashed this out before on this forum, and believe me when I say I really don't want to do it again, but...there have been computer systems designed with their major aim being minimization of the life-cycle cost of the system, software and hardware included. (I'm thinking of the object-oriented systems here.) You can argue that no such system has yet measurably achieved such an objective, and you may well be right. But that's not the same as arguing that improving the performance of a machine is the ONLY way to improve its life-cycle cost. Do you really believe it is? Bob Colwell ..!uunet!mfci!colwell Multiflow Computer or colwell@multiflow.com 31 Business Park Dr. Branford, CT 06405 203-488-6090
rfg@ics.uci.edu (Ron Guilmette) (10/17/89)
In article <6535@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > >About the only hardware feature I used to pray for was "breakpoint at >data address". It turns out that there are several ways to do this on >conventional hardware. I noticed that the i860 has this feature on-chip. I don't know if it is available with the CMMU's for other current 32-bit micros (e.g. 88k, MIPS, SPARC). If anyone else knows, please tell me. Now if we could just get support for such things via standard UNIX ptrace calls, and then get the GNU Debugger (gdb) to actually bring such facilities out to the user's level... // rfg
bwong@sundc.East.Sun.COM (Brian Wong) (10/23/89)
In article <130800001@peg> robert@peg.UUCP writes: >Why should we welcome a continual increase in MIPS (VUPS or whatever)? >We have enough trouble designing programs which work without error at the >moment. These will just get to the error state faster with more power. You have a point; correctness is a first requirement for solving problems. But there is a large class of problems which have an essentially unlimited appetite for computational power. Simulations, for example, seem to be like fractals - no matter how precise you can make them, if you had about 10x computing power you could make them more precise and do X or Y interesting things with them. For years now the engineering community has consistently demanded MORE computational power to solve increasingly complex problems. There is also the ever-increasing set of "basic" software without which users of any sophistication will not do without. Ten years ago, a lot of users would have balked at the thought of spending "all those cycles and comm time for all those checksums" in a scheme like TCP/IP. Nobody (well, almost nobody) thinks about the efficiencies of those checksums anymore - we'd rather have the data "just get there, baby." Graphical user interfaces are a good example. Five years ago, the MAC was slow because it spent all of its time running the UI. Now we all demand the graphics UI. Networked windowing systems are another example. I'll wager that five years from now, network window systems will become a sine qua non in software development. And yet it is only the most recent generation of inexpensive workstations (DEC3100, DG Aviion, SPARCstation 1, HP 835) that have really had the gas to drive these at acceptable speeds. The horizon keeps moving out. The expert systems that require the biggest iron we can afford will become common -- even uninteresting -- subsystems of software products, and the 10, 20, 100 mips that they consume (along with the 5 mips the window system consumes, and the .4 mips the network consumes) will merely represent the overhead of "doing useful work" in the future. And finally, for the collegue of mine who once snapped at the poor programmer trying to debug a PL/I program using the optimizing compiler "I suppose it's better to get the wrong answer faster?" He was only half right - use the checkout compiler on a faster box, so that you CAN get the wrong answer faster - and then to fix it. -- Brian Wong Sun Microsystems bwong@sun.com Vienna, Va. 703-883-1243
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (10/24/89)
In article <10803@sundc.East.Sun.COM> bwong@sundc.East.Sun.COM (Brian Wong) writes: >In article <130800001@peg> robert@peg.UUCP writes: >>Why should we welcome a continual increase in MIPS (VUPS or whatever)? >>We have enough trouble designing programs which work without error at the >>moment. These will just get to the error state faster with more power. > >You have a point; correctness is a first requirement for solving problems. Ah, were this were so! :> Despite having toiled for years (UD and SRIF Kalman filtering, now computer stuff) trying to "sell" correctness I have always come across the "we must have it faster, who cares if its a few % wrong philosphy". Fortunately in Kalman filtering it was (after years of sweat) possible to have both. If my window system goes 2x faster, but sometimes draws one pixel in the wrong place I may be happy ... If my OS core dumps, of course, I'm real unhappy. Sometimes enough faster covers for a little wrong :> Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks