Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uflorida!condo.cis.ufl.edu!bp From: bp@condo.cis.ufl.edu (Brian Pane) Newsgroups: comp.os.minix Subject: Re: Bloat costs Message-ID: <23495@uflorida.cis.ufl.EDU> Date: 10 Jun 90 00:27:54 GMT References: <21579@nigel.udel.EDU> Sender: news@uflorida.cis.ufl.EDU Reply-To: bp@condo.cis.ufl.edu (Brian Pane) Organization: UF CIS Department Lines: 92 In article <21579@nigel.udel.EDU> V2057A%TEMPLEVM.BITNET@cornellc.cit.cornell.edu (Juan Jose Noyles) writes: >Brian, you sound like a freshman that just decided to stop cutting classes and >impress your friends with the new words you've learned. There doesn't seem to >be any hint of experience in your tome. Don't get me wrong, this isn't a per- >sonal flame, because I used to talk like that too. > I didn't use the software engineering buzzwords to impress anyone. In fact, I generally consider "software engineering" an oxymoron. I pointed out the problems of maintainability, readability, portability, etc. because they are real problems which actually exist outside the minds of CS students and professors. I used to think efficiency was the primary consideration in programming. I now know better. >You said a lot of trash that amounted to 'when everyone has big, fast machines, >who cares that we waste a few cycles doing nothing? My big, fast machine won't >notice, and neither will my users.' Wrong, dude. If you'd been in class and >concentrated on understanding why a fast search on a slow machine beats the >pants off of a slow search on a fast one, you'd also understand why users are >always complaining about stupid programmers and the schools that graduate them. > I'm afraid you've completely misinterpreted my posting. I did *not* say that fast hardware justifies bad algorithms. I said that we shouldn't have to write bizzare code that exploits the peculiarities of a particular machine. Spending an hour debugging a partitioning routine so that you can replace an insertion sort with a quicksort is a productive activity. The resulting program will be more efficient than the previous version, regardless of the underlying instruction set, data bus width, register limitations, etc. (Yes, some "efficient" algorithms thrash badly with virtual memory systems, but let's not venture down that path of discussion.) Spending an hour rewriting your insertion sort in assembly language to take advantage of the fact that only the CX register can be used in an autopostdecrement mode is not a productive activity. One important difference between "big, fast" machines and "small, slow" machines is the fact that the former provide a much better base than the latter for the implementation of efficient algorithms. I think I can clarify my point (and avoid a lengthy stream of followups calling me an ignorant undergrad) by comparing two machines. The first is a 68030-based workstation in the department's UNIX lab; I'm using it right now. The second is one of the 80535-based 8-bit single-board computers with which I'm building a network at work. I do most of my programming for both machines in C, and--despite your poor opinion of my intellectual ability--I write efficient code. I don't allocate more memory than I need, I try to use the algorithm with the best O(f(N)) for often-repeated routines, etc. However, the 68030 ends up executing much better code than the 80535, because our 80535 compiler must struggle to produce code for the very limited architecture instruction set and register set. The 80535 was designed to be programmed in assembly language, while the '030 provides many instructions to support high-level language programming. To get my C programs to run efficiently on the 80535, I must introduce all sorts of "optimizations" (char instead of int, avoiding arrays whenever possible, lots of temporary register variables, static variables that should logically be automatic, etc.) that have nothing to do with the efficient functioning of my algorithms. The alternative is assembly language, which is economically unfeasible. On the '030, gcc produces fast enough code that I have never had to bother studying the assembly language it produces. One of my co-workers is digitally storing and playing back sound with the 80535; doing so requires a ridiculous amount of bank-switching. With a 32-bit address bus, the workstation doesn't have to do bank-switching. Of course, many people who posted or e-mailed a followup to my original article have emphasized the evils of large CODE size, but nobody has yet acknowledged that emerging applications need lots of DATA space and need to access it very quickly. Of course, it is a bit ridiculous to compare a 32-bit CPU with an 8-bit microcontroller, but the comparison helps to emphasize the correlation between software evolution and hardware power. The benefit of powerful hardware is not that it enables bad programmers to hide their stupidity, but rather that it enables good programmers to develop new programs--and new types of programs--that would have been impossible with fewer MIPS. >There's a difference between efficiency and effectiveness. I hope you learn it >before you graduate. Efficiency: You write compact code that doesn't excessively strain computer resources or do anything incredibly stupid. Effectiveness: You get the program done, thus avoiding unemployment. The people you're working for sell lots of copies and avoid bankruptcy. The program is not as elegant as it might be, but it doesn't kill anybody. If you get enough complaints, you fix the program. If you get enough compliments, you fix the program. ------------------------------------------------------------------------- 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" #endif -------------------------------------------------------------------------