home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2116 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  4.6 KB

  1. Path: sparky!uunet!usc!rpi!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: tdarcos@mcimail.com (Paul Robinson)
  3. Newsgroups: comp.compilers
  4. Subject: [TDR] Fat Code
  5. Keywords: optimize, design
  6. Message-ID: <93-01-043@comp.compilers>
  7. Date: 8 Jan 93 02:51:12 GMT
  8. Article-I.D.: comp.93-01-043
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: Paul Robinson <tdarcos@mcimail.com>
  11. Organization: Compilers Central
  12. Lines: 76
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. "Fat Code" is where an application is overly bloated, either because the
  16. compiler is inefficient (more about reasons you might want that in
  17. "Compile Time vs.  Run Time"), because the programmer has chosen a bad
  18. implementation of a particular means to perform an algorithm, or because
  19. the programmer has coded something using a standard method which is in and
  20. of itself a heavy user of resources.  Let me look at all of these.
  21.  
  22. When compilers first came out, the compiler writers were, in almost all
  23. cases, employees of the hardware manufacturer.  Since they could get
  24. access to the designers of the hardware, they could find out how to do
  25. things in ways which are much more efficient than the average user.
  26.  
  27. For example, in certain cases, a shift is more economical than a multiply
  28. by two.  But not if the user wants the overflow condition that a multiply
  29. might generate and a shift might not, or vice versa, or that one would
  30. generate one class of condition and the other wouldn't.
  31.  
  32. Now, compilers are written by employees of companies that in some cases do
  33. nothing but sell compilers.  Therefore their interest is in pushing
  34. product, not in the tweaking for performance that in some cases can help.
  35. On the other hand, there can be enough of a market for certain kinds of
  36. compilers as to be worth it to implement some of them to be more efficient
  37. in certain operations.
  38.  
  39. Coder bloat in "fat code" occurs when the user writes an algorithm using a
  40. real resource hog of an application with no attempt to do it differently,
  41. or maybe the person is not-well trained enough that they don't know any
  42. other way to do this.  One example would be doing a bubble sort on a large
  43. number of elements, but because this is a dog on performance, reading the
  44. entire database - say 100,000 records - into memory.  This isn't a good
  45. example because most large computers, COBOL compilers and even MS-DOS and
  46. DBASE have built in sort routines, but you get the idea.
  47.  
  48. Algorithm bloat is somewhat related to Coder Bloat, but it is much more
  49. subtle.  Perhaps one case would be use of a standard sort routine supplied
  50. with an application that is only 1/10 as efficient as a different method.
  51. I know there is a difference but I can't quantify it as yet.
  52.  
  53. Then there is the bloat caused simply by USING a high-level language.
  54. For example - and this seemed to be a universal constant - any FORTRAN
  55. program, even one consisting of one CALL EXIT statment, would use 18
  56. blocks of disk space on a PDP-11 (one block is equivalent to 512 words),
  57. and it would take 18 pages on a UNIVAC VS/9 mainframe (this is equivalent
  58. to an IBM 360 or 370 (now called the 3090)).  Both use 18 units of disk
  59. space as a minimum.
  60.  
  61. If you programmed in Basic, if you used an interpreter, a great deal of
  62. the code is used for safety checks, i.e. range checks, INPUT statement
  63. limits, and on multi-user systems, privelege checks.  All of this uses
  64. space and makes the interpreter larger.  If your program could be
  65. compiled, a lot of the run-time library (that often was never used) was to
  66. check for things.
  67.  
  68. Now we have "smart linkers" that can decide not to include part of the
  69. Run-Time library if you don't use it.  Funny but we had the same thing on
  70. mainframes in 1978, it simply placed routines by name and if they weren't
  71. called, they weren't included.
  72.  
  73. Now we have MS-Windows.  This brings new meaning to the term "Resource
  74. Hog."  Like calling Niagra Falls "moist."  One person referred to MS
  75. Windows as being "4 Meg of memory to play Solitaire."
  76.  
  77. There is an important point to make about fat code, and not just in
  78. respect to something like Microsoft Windows; if a program is small it will
  79. run in a smaller space.  And it will probably run faster.
  80.  
  81. I once pointed out something important to someone about a good reason to
  82. develop code that is usable on an 8086.  Because if it runs at a
  83. reasonable speed on a 4 MHZ 8086, run it on an 80486 and it will run like
  84. a "bat out of hell."  Even with all the overhead of MS Windoze, it will
  85. still give MUCH better performance.
  86. ---
  87. Paul Robinson -- TDARCOS@MCIMAIL.COM
  88. -- 
  89. Send compilers articles to compilers@iecc.cambridge.ma.us or
  90. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  91.