home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10820 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.5 KB
  1. Xref: sparky comp.arch:10820 comp.lang.misc:3733
  2. Newsgroups: comp.arch,comp.lang.misc
  3. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  4. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  5. Subject: Re: A challenge to the anti-goto (C code included!)
  6. Message-ID: <Bxv6os.Ht5@mentor.cc.purdue.edu>
  7. Sender: news@mentor.cc.purdue.edu (USENET News)
  8. Organization: Purdue University Statistics Department
  9. References: <1992Nov3.053951.7786@cognos.com> <1992Nov5.203759.8030@linus.mitre.org> <nevin-171192000126@90.20.3.218>
  10. Date: Tue, 17 Nov 1992 14:24:27 GMT
  11. Lines: 74
  12.  
  13. In article <nevin-171192000126@90.20.3.218> nevin@apple.com (Nevin ":-]" Liber) writes:
  14. >In article <1992Nov5.203759.8030@linus.mitre.org>, bs@gauss.mitre.org
  15. >(Robert D. Silverman) wrote:
  16. >> Dr. Rubin's main rule is:
  17.  
  18. >> "The code should run as fast as possible"
  19.  
  20. >> For him, all other considerations are secondary. Who are you to tell
  21. >> him what his priorities should be?
  22.  
  23. >Because that isn't what he is asking for.  His model of efficiency totally
  24. >ignores OS overhead (eg page sizes, working set sizes, etc.), for instance.
  25. > I've also never seen him deal with instruction or data caches or
  26. >pipelining.  All of which is extremely important if you need to do the
  27. >micro-optimisations that Herman always talks about.
  28.  
  29. I am quite aware of these problems.  I do not see any major run-time code
  30. bloat with the optimizations I use, and I wish that hardware manuals would
  31. do a good job of explicitly listing pipelining considerations (some do,
  32. such as the Crays and Cybers) so that the programmer can take those into
  33. account.
  34.  
  35. I have suggested that the compiler should communicate with the programmer
  36. and discuss various alternatives.  The programmer, having imagination, may
  37. then even come up with more alternatives for the compiler to consider.
  38.  
  39. >> There are times when readability, portability, and ease of maintenance are
  40. >> of primary importance. There are times when they don't matter at all.
  41.  
  42. >Only when the results don't matter at all.
  43.  
  44. Here is part of what I would have wanted to write for my code.  Since the
  45. languages do not allow it, and do not have the capabilities of taking into
  46. account the information needed for fast code, *I* have to arrange it.
  47.  
  48. Comment: this code is part of a loop which will be executed many times.
  49.  
  50.     n = 0; m = 0;
  51.  
  52. irp{    g = ...;    ##This point will be reached 3.08 times/loop on the
  53.                 average
  54.     switch(g){    #*successive values are half as likely
  55.     case 1:    n += 1; repeat;
  56.     case 2:    exit label1;    ##this most common exit (77%) has no further
  57.                     processing within the loop cycle
  58.     cases 3, 5, 6, 9 -12:  repeat;
  59.     case 4: h = ...; m = ib>>h; exit label1;
  60.     case 7: h = ...; m = (ib>>1)|(ib>>h); exit label1;
  61.     case 8: ,,,
  62.     higher cases:  
  63.  
  64.     I will leave out the rest of the irp; it gets worse, but must be there
  65.     There are exits to labelh and also repeats in it
  66.     
  67.     }
  68.  
  69. labelh:
  70.  
  71.         ..................
  72.  
  73. label1:    nn[index] = n; mm[index]=m;    ## End of loop
  74.  
  75. Now an optimizing compiler SHOULD certainly move the initialization to the end
  76. of loop.   It should also move the case 1 code to before the g = ... statement,
  77. but can it with the present restrictions?  This moves the case 1 code outside
  78. the switch block!  Also the repeat cases all go to a location outside the
  79. switch block, or its dropthrough.
  80.  
  81. Do you trust your compiler to do all of this?  I do not.
  82. -- 
  83. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  84. Phone: (317)494-6054
  85. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  86. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  87.