woolstar@cit-vax.Caltech.Edu (John D Woolverton) (03/28/89)
> Writes: Barry Shein, Software Tool & Die > As an analogy, who needs a 15MIPS workstation? Very few people, but > they're available now and are cost competitive with slower > workstations so, hey, that's what we all want. The others will wither > on the vine. One of the side effects of all these bigger and faster computers are that more options and effects are being added, and this is good but it also allows less efficient and sloppier code. Given, that all applications don't need to be written in assembly any more, but there are quite a few programs that I have looked through, that are incredibly sloppy. It is sad that as machines go faster, some of the same programs we always used go slower. John d Woolverton, programmer. woolstar@csvax.caltech.edu
jbn@glacier.STANFORD.EDU (John B. Nagle) (03/29/89)
In article <10167@cit-vax.Caltech.Edu> woolstar@cit-vax.Caltech.Edu (John D Woolverton) writes: >It is sad that as machines go faster, some of the same programs >we always used go slower. Also bigger. Run "size" on, say, "ps", on a Sun. However, there are applications which need power well beyond what is available today. I have some designs for a geometry-based AI system that will take 1000 to 10,000 MIPS. There are simple algorithms in early vision that take twenty minutes per frame on a Sun 4. We need serious MIPS to deal with the physical world. John Nagle
bzs@BU-CS.BU.EDU (03/30/89)
From: glacier!jbn@labrea.stanford.edu (John B. Nagle)
> Also bigger. Run "size" on, say, "ps", on a Sun.
SunOS 4.0.1:
skuld% size /bin/ps
text data bss dec hex
25880 4616 2224 32720 7fd0
-Barry Shein, Software Tool & Die
There's nothing more terrifying to hardware vendors than
satisfied customers.dennis@YANG.CPAC.WASHINGTON.EDU (Dennis Gentry) (03/30/89)
If anything, it looks like Sun's code is getting smaller. > SunOS 4.0.1: > > skuld% size /bin/ps > text data bss dec hex > 25880 4616 2224 32720 7fd0 SunOS 3.5: dennis@yang% size `which ps` text data bss dec hex 106496 16384 48364 171244 29cec Dennis.
weiser.pa@XEROX.COM (03/30/89)
>If anything, it looks like Sun's code is getting smaller.
Shared libraries.
-markdoering@kodak.UUCP (Paul F. Doering) (04/01/89)
In <10167@cit-vax.Caltech.Edu> John D Woolverton writes on the subject of the implications of powerful systems -- > One of the side effects of all these bigger and faster computers > are that more options and effects are being added, and this is good > but it also allows less efficient and sloppier code. Given, that > all applications don't need to be written in assembly any more, > but there are quite a few programs that I have looked through, > that are incredibly sloppy. > > It is sad that as machines go faster, some of the same programs > we always used go slower. John, it seems that at least part of the history of technology has involved making it possible for humans to survive while becoming progressively less competent at some previously necessary skill. We can cite cooking, driving, hunting, farming, and --alas -- coding. (No flames, please, from cooks, chauffeurs, hunters, or farmers. I'm referring to the bulk of humankind, not to those of you who have elected to remain proficient.) In his must-read book "The Media Lab: Inventing the future at MIT" Stewart Brand cites Nicholas Negroponte's observation that eventually our appliances will have more MIPS than our computers. I think that we can expect those refrigerator-driving chips to be substantially better programmed than most modest-sized computers will be, because there is a clear way for an accountant to evaluate what a business has spent on the chip's education but no clear way to assign $-loss to an inefficient package running in the company's desktops. Software sells hardware. Bigger programs sell more hardware. The incentive is there for our suppliers, John: sloppiness will not be penalized, because _permitting_ sloppiness enriches the vendors. Portia Isaacson commented that someday Computer Science would be no more august than Refrigerator Science is today. She may have understated the case. Maybe the _real_ skill will belong to the programmers of refrigerators. -- ======================= =================================================== Paul Doering (for self) Once a new technology rolls over you, if you're not rochester!kodak!doering part of the steamroller, you're part of the road. ======================= ========================== -Stewart Brand =========
davis@COMMUNITY-CHEST.MITRE.ORG (dave davis) (04/03/89)
John Woolverton writes: > One of the side effects of all these bigger and faster computers > are that more options and effects are being added, and this is good > but it also allows less efficient and sloppier code. Given, that > all applications don't need to be written in assembly any more, > but there are quite a few programs that I have looked through, > that are incredibly sloppy. There is a common myth in computer science that if one codes it in assembler it is somehow magically faster, better, and more professional. Remember, a lousy design is still lousy in assembler or in any high-level language. There are some published studies which show that the variaton in execution speed between good designs for a problem and the worst designs for the same problem is a factor of one to 1500! My objective is not to flame John, but to point out some trends. Industrys desperate need for more software, cheaply, is pushing higher-level languages and efforts to somehow automate more of what analysts and programmers do (ex: environments, expert systems, 4GLs). A more subtle trend is the use of design methodolgies. These have the goal of making a system design more understandable, and doable, rather than the goal of making the code fit on the machine. So, what we are going to use all those MIPs for is to run our relational database, data dictionary tools, deisgn aids, configuration manager, etc. while compiling, debugging, and integrating. So, a programmer is going to need about 20MIPs at his desk. ================================================================= Dave Davis MITRE Corp. McLean, VA