Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: More mips
Summary: roll on
Message-ID: <6535@pt.cs.cmu.edu>
Date: 16 Oct 89 03:05:17 GMT
References: <771301127@8909291517.AA00260@maxwell.ece.c> <130800001@peg>
Organization: Carnegie-Mellon University, CS/RI
Lines: 28


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