Xref: utzoo comp.os.minix:11109 comp.unix.xenix:11968 comp.realtime:686 comp.arch:16393 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!uflorida!retiree.cis.ufl.edu!bp From: bp@retiree.cis.ufl.edu (Brian Pane) Newsgroups: comp.os.minix,comp.unix.xenix,comp.realtime,comp.arch Subject: Re: Bloat costs Message-ID: <23473@uflorida.cis.ufl.EDU> Date: 8 Jun 90 17:47:48 GMT References: <442@van-bc.UUCP> <266577FA.6D99@tct.uucp> <1990Jun1.200333.10672@pmsmam.uucp> Sender: news@uflorida.cis.ufl.EDU Reply-To: bp@beach.cis.ufl.edu (Brian Pane) Organization: UF CIS Department Lines: 79 In article <1990Jun1.200333.10672@pmsmam.uucp> wwm@pmsmam.UUCP (Bill Meahan) writes: >In article wsd@cs.brown.edu (Wm. Scott `Spot' Draves) writes: >>In article <266577FA.6D99@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >> According to jtc@van-bc.UUCP (J.T. Conklin): >> >> [stuff deleted] >> >>One of the wonderful things about 20Mip 32Mb workstations is that I >>don't have to worry about eff. when writing most code. I can >>concentrate on other issues such as clarity of code, speed of >>execution, speed of development, fancy features, ... >> >>by "eff." i mean "frugal of code and data". >> > >May I be among the first to say HORSEPUCKY! > >There seems to be a mindset among many CS majors that >"memory is cheap and hardware is fast, so why worry about efficiency?" > >This kind of thinking is the result of looking only at chip prices and >the latest hot-rod announcements. In truth, only a SMALL subset of the If such a mindset exists, it is not because of the abundance of powerful hardware. It is because CS majors are taught to build robust, maintainable, and therefore seemingly elegant programs rather than compact and clever programs. If we get used to writing ruthlessly brilliant programs, we'll only add to the "software crisis" when we graduate. I agree that efficiency is important, but it must be kept in its proper perspective. This group is devoted to the implementation of a UNIX-like OS on an architecture that should have been allowed to die ten years ago. No matter how well you write your C code, an average compiler will probably produce disgracefully slow executables. There is little to be gained by writing efficient C programs for inefficient machines. You *can* write fairly efficient code for the 8086--in assembly language. However, few people have that much time to waste. While you're shouting about the expense of "improved" software and the expense of the hardware on which such software must run, don't forget about the cost of programmer time. Finally, note that large and "inefficient" programs advance the state of the art in software more often than small and clever programs. Consider X Windows. It is a huge system designed for flexibility rather than efficiency, and it requires significant hardware power, but it has revolutionized the way we use computers. >Maybe all CS majors should be forced to take a few economics courses along >with the rest of their curriculum! > Don't blame us for the economic problems of software development; blame the EE's who design the hardware. With an orthogonal architecture and a good compiler, you can write maintainable programs in high-level languages and still produce products that run quickly on machines with a lot fewer than 20 MIPS. >FAST, SMALL, CHEAP <--- Pick any 2, you can't have all 3. Not yet. And not ever, if we all devote our efforts to optimizing tiny programs for tiny machines. 20-MIPS workstations will become affordable only when lots of software is available for them. >Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwm >I speak only for myself - even my daughter's cat won't let me speak for her! -Brian F. Pane ------------------------------------------------------------------------- Brian Pane University of Florida Department of Computer Science bp@beach.cis.ufl.edu Class of 1991 "If you can keep your expectations tiny, you'll get through life without being so whiny" - Matt Groening #ifdef OFFENDED_ANYONE # include "disclaimer.h" // Sorry to indulge in such 8086-bashing, folks, but I had a point to make. #endif -------------------------------------------------------------------------