robert@peg.UUCP (10/14/89)
In reply to Craig Jackson's comments, 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. Instead of pushing for a continual increase in power, how about looking at, for example (and this is *only* an example), better hardware to aid program correctness and completeness. The problem is the same, as far as I can see, as that of most of economics. Economics traditionally has growth being the sole reason for existance. If there is not a steady growth in an economy the that economy is dead, as far as t.e. is concerned. Forget that that economy may actually be doing the best things for all the people in it etc. This should not be in here, perhaps, but again, let's use what we have (and understand it fully) BEFORE moving on. Look ahead, don't leap. Robert McArthur Pegasus Networks, Byron Bay, NSW, 2481 Australia robert@peg.pegasus.oz.au
swarren@eugene.uucp (Steve Warren) (10/16/89)
In article <130800001@peg> robert@peg.UUCP writes: >In reply to Craig Jackson's comments, > >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. This is most humorous ;^). You should post this to rec.humor. But you left out the smilies. It is especially funny to think of the billions of dollars everyone is spending collectively on computing hardware, when all that is ever accomplished is errors ;^). Seems like after a while we would all realise that nothing is being generated except errors, and we would all take up basket weaving ;^). --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
henry@utzoo.uucp (Henry Spencer) (10/17/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. Many of us have little reason to rejoice at higher power, at least until the software catches up and lets us make intelligent use of all those extra cycles. (There is much more that the software could be doing for us.) However, those who do need more power need it *very badly*. The computational-aerodynamics people, to take one example, would be overjoyed to be able to buy processors 1000 times the speed of existing ones. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dricejb@drilex.UUCP (Craig Jackson drilex1) (10/17/89)
In article <130800001@peg> robert@peg.UUCP writes: >In reply to Craig Jackson's comments, > >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. >Instead of pushing for a continual increase in power, how about looking >at, for example (and this is *only* an example), better hardware to aid >program correctness and completeness. I never meant to imply that hardware devoted to program correctness was unappreciated. I personally do most of my work on the Unisys A-Series, which offers such things as hardware array-bounds checking. However, they found that they had to defeat that feature to make a usable C compiler... I welcome any hardware support of program testing and analysis. I feel that many of today's MIPS could be better spent adding a few gate-delays for such features. However, that aside, I also like writing programs on machines that have enough speed to produce a decent user interface without coding balls-to-the-wall (introducing more complexity). I like writing programs on machines which have enough speed to allow me to leave all of my internal assertion checks in the finished program. I like writing programs on machines which are fast enough to have sophisticated programming- support tools. (Not that many of those have been written yet.) >The problem is the same, as far as I can see, as that of most of economics. >Economics traditionally has growth being the sole reason for existance. If >there is not a steady growth in an economy the that economy is dead, as far >as t.e. is concerned. Forget that that economy may actually be doing the >best things for all the people in it etc. I used to have poster with the slogan "Growth is the only evidence of life". Not that this is really true, but it does give one thought. I think you should think of this desire (on the part of politicians, economists, and hardware-designers) as the desire to each day, leave the world a little better than the day before. I think that the view that growth is undesirable comes from differences of opinion about what is better for the world. >This should not be in here, perhaps, but again, let's use what we have >(and understand it fully) BEFORE moving on. Look ahead, don't leap. > >Robert McArthur >Pegasus Networks, >Byron Bay, NSW, 2481 >Australia > >robert@peg.pegasus.oz.au -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
bzs@world.std.com (Barry Shein) (10/18/89)
The correct way to state the "do we need more MIPS?" argument is something like this: 1. There exists a percentage of users who, no matter how fast computers become in the foreseeable future, will need even more speed. 2. There are two factors making the percentage smaller over time, the steady and rapid increase in office and other clerical uses of computers and the increase in speed we are seeing (that is, some users are dropping out of the hunger category simply because they have become sated for the time being.) 3. A good test of whether or not someone is in the first category or not is to ask the question: "Given $X for your computing needs, and no more, for the next year what would you spend it on?" If they say CPU then they're probably in the first category. If they say a faster CPU would be nice but I guess right now I'd have to buy (some neat applications software, more disk, printer, whatever) then they're probably not in the first category, just like to think they are. Many more people are in the "just like to think they are" category than most of us are led to believe. They say that CPUs must get faster but, instead of buying faster CPUs already available, they buy things like nifty laser printers or graphics packages for the same dollars. Granted the shrinking percentage of power-hungry users still control hefty dollars and that's what keeps that section of the industry humming but don't discount the trends. There may well be a point beyond which even folks like DOD can't keep the sheer race for MIPS viable. I/O bandwidth is probably another competing frontier. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
dmocsny@uceng.UC.EDU (daniel mocsny) (10/18/89)
In article <1989Oct17.192955.29370@world.std.com>, bzs@world.std.com (Barry Shein) writes: > 1. There exists a percentage of users who, no matter how fast > computers become in the foreseeable future, will need even more speed. This I agree with, though I think the percentage is 100. > 2. There are two factors making the percentage smaller over time, the > steady and rapid increase in office and other clerical uses of > computers and the increase in speed we are seeing (that is, some users > are dropping out of the hunger category simply because they have > become sated for the time being.) OK. Let's distinguish clearly between how much computer we "need," and how much we "can use." The reason office and clerical users are getting saturated right now is not because computers have solved all their problems and they are now sitting around twiddling their thumbs. If anything, these workers still appear to have plenty of remaining profitable opportunities to apply Information Power. The problem is, viewing the computer as an ergonomic device, to get the computer to do X amount of work, the user must sit there and perform f(X) amount of work (typing in commands, searching for and reading TFM, wondering why the serial cables don't work, waiting on hold at the user support number, unjamming the printer, looking for backup copies of trashed files, etc. etc.). The amount of work the user can perform then limits the amount of computer power the worker can productively exploit. Because the overall ergonomic performance of computer systems today is still rather poor, very few people have the type of scalable, redundant problems (such as airline ticketing or weather forecasting) that allow a handful of computer operators to effectively use powerful hardware. To say that people don't "need" any more computer power is to say that they have no further aspirations. That is plainly silly. As soon as hardware/software reduces f(X) for one task enough to give the user some spare time, the user will then advance to the next profitable task. The real problem is that the industry cannot produce general-purpose computing machines that keep themselves doing useful things at full tilt without requiring constant attention from highly skilled users. Dan Mocsny dmocsny@uceng.uc.edu
aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) (10/19/89)
>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. >Instead of pushing for a continual increase in power, how about looking >at, for example (and this is *only* an example), better hardware to aid >program correctness and completeness. ...hardware to aid program correctness and completeness: Like, array bounds checking? Overflow detection for integers? All of this can be and has been done on existing systems. No need for special hardware support. But still, the vast majority of programs in the USA [*] run without any of these forms of compiled in security. Why? Programs run faster when run-time checks are turned off. QED. Several compiler systems do a damned good job of removing run-time checks that they can prove to be unnecessary. Maybe one day I'll be able to use one. But until then, improved run-time checking requires improved performance. "But not just brute force - maybe special, parallel, hardware?" Maybe - but if the extra hardware slows you down by factor X, and the cost of inline checks in a serial instruction set are Y<X, then people will build faster serial processors - and still customers will turn off the run-time checks. This is one of the things I find encouraging about the trend to VLIW (I consider machines like the new IBM chip with multiple slots semi-VLIW): so maybe your compiler cannot fill all the slots all the time. Maybe we could put run-time checks into some of the unused slots, with no loss of performance due to extra instructions. Then, if there is a $$$ benefit from the checks, maybe we'll start using not just idle resources for them. [*] Note that I didn't say all, and that I carefully restricted it to the USA. Not that I believe that the majority of programs outside the USA use run-time checks, but I have heard about systems, like Northern Telecom's, that use run-time checks in production code. Encouraging. -- Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com 1101 E. University, Urbana, IL 61801, USA. {uunet!,}uiucuxc!udc!aglew My opinions are my own; I indicate my company only so that the reader may account for any possible bias I may have towards our products.
bzs@world.std.com (Barry Shein) (10/21/89)
>To say that people don't "need" any more computer power is to say that >they have no further aspirations. That is plainly silly. As soon as >hardware/software reduces f(X) for one task enough to give the user >some spare time, the user will then advance to the next profitable >task. The real problem is that the industry cannot produce >general-purpose computing machines that keep themselves doing useful >things at full tilt without requiring constant attention from highly >skilled users. > >Dan Mocsny It's not that they have no further aspirations, it's that they have no further software. And that's not silly. You can hypothesize all this software which "they" will find useful and will require all these extra cycles but it remains just that, a hypothesis, an extrapolation of past experience which may or may not be valid. I will grant it will be valid in some applications domains but in others it may very well not be valid. In fact, they'll scream for more cycles *after* that software shows up, not in anticipation of it. If we have to hypothesize non-existant software to soak up the cycles we already have, then we have entered a very different realm indeed from a very few years ago. The current thinking in this field is reminiscent of the "rising expectations" of the 60's where the common view was that of ever-expanding, limitless resources and economies. (More) prosperity is just around the corner. I'm not saying this thinking is wrong, but I am saying its proponents seem unexamined, zealotry is a word which comes to mind. -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
dmocsny@uceng.UC.EDU (daniel mocsny) (10/21/89)
In article <1989Oct20.234510.955@world.std.com>, bzs@world.std.com (Barry Shein) writes: > It's not that [ users ] have no further aspirations, it's that they have no > further software. And that's not silly. I'm sorry if the tone of my post sounded excessively hostile. I see now that I misunderstood your use of the word "need." When I am hungry, but have neither food nor a dish to put it on, I still need to eat. However, I guess if I speak of needing a dish, I mislead. > You can hypothesize all this software which "they" will find useful > and will require all these extra cycles but it remains just that, a > hypothesis, an extrapolation of past experience which may or may not > be valid. I will grant it will be valid in some applications domains > but in others it may very well not be valid. The past history of the computer industry has many amusing episodes beginning with statements like: "Nobody will ever need ... " or "The maximum worldwide demand for < X > will be at most ... " Prognosticators have been very good at underestimating the demand for information processing power. I am understandably skeptical when I hear similar statements today, especially when I am acutely aware that my own information needs are far from satisfied (a function of both inadequate hardware and inadequate software). However, I agree with your concern about the software lag. The software complexity necessary to fully exploit powerful computers appears to increase in proportion to those machines' power. And yet, as we all know, while the hardware power increases exponentially, software complexity increases arithmetically (if at all). > In fact, they'll scream for more cycles *after* that software shows > up, not in anticipation of it. This is true. Both users and experts have a profoundly difficult time grasping the potential of any new development until it is up and running before their eyes...or perhaps, before their competitors' eyes... > If we have to hypothesize non-existant software to soak up the cycles > we already have, then we have entered a very different realm indeed > from a very few years ago. Well, I think that if we look at the size of the existing software library, we would be hard-pressed to find many computer users who are in fact using all the software they might benefit from right now. (Does any individual alive even *comprehend* what all that software can do?) If the hardware speed enthusiasts want to keep the world safe for faster hardware, then they are eventually going to have to do something about not only the gap between hardware and software, but between software and users. What? Dunno. But for starters, having computers that are unable to run major chunks of the existing software library, even inefficiently, sounds to me like a big, big problem. (However, this is again as much a problem amenable to new software (emulators, etc.) as it is to new hardware (e.g., overlapping instruction sets).) Another possible tactic is for hardware vendors to fund development of complex, compute-intensive software, and then give it away to users when they buy hardware. If you can successfully bundle enough software to insure the box is choked the second it gets installed, and the software is worth running, then you've got your repeat business right there. That shouldn't be too hard to do; a few generous grants to the Free Software Foundation would probably do the trick. Dan Mocsny dmocsny@uceng.uc.edu
johnl@esegue.segue.boston.ma.us (John R. Levine) (10/23/89)
In article <2540@uceng.UC.EDU> dmocsny@uceng.UC.EDU (daniel mocsny) writes: >Another possible tactic is for hardware vendors to fund development of >complex, compute-intensive software, and then give it away to users >when they buy hardware. If you can successfully bundle enough software >to insure the box is choked the second it gets installed, and the >software is worth running, then you've got your repeat business right >there. ... Some of us remember when such programs were called "operating systems" and they were bundled in free with the hardware. Then due to a conbination of government action against IBM and everybody noticing that they were spending as much on the free software as they were on the hardware, they started to charge for the software. My experience in the software business tells me that we software types will have no trouble pissing away whatever hardware resources we can get our hands on, without subsidies from hardware vendors. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe