home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10500 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.2 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!spool.mu.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.arch
  4. Subject: Re: Hardware Support for Numeric Algorithms
  5. Followup-To: comp.arch
  6. Date: 7 Nov 92 09:01:14
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 101
  10. Message-ID: <TMB.92Nov7090114@arolla.idiap.ch>
  11. References: <BwIwEB.J1A@mentor.cc.purdue.edu> <BwJ1rB.pz@rice.edu>
  12.     <1992Oct22.164414.12708@newshost.lanl.gov> <Bx78zu.395@rice.edu>
  13.     <1992Nov4.183718.5242@newshost.lanl.gov> <2230@titccy.cc.titech.ac.jp>
  14. Reply-To: tmb@idiap.ch
  15. NNTP-Posting-Host: arolla.idiap.ch
  16. In-reply-to: mohta@necom830.cc.titech.ac.jp's message of 6 Nov 92 12:31:52 GMT
  17.  
  18. mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes
  19. >>In article <Bx78zu.395@rice.edu>, preston@dawn.cs.rice.edu (Preston Briggs) writes:
  20. >>Using C as an assembler is doable, in that you can express (almost)
  21. >>every optimization in the source code.  The result is machine dependent,
  22. >>ugly, unmaintainable, and I don't recommend it to anyone, but doesn't
  23. >>really require any additional optimization -- very similar to assembly
  24. >>language programming.
  25. >
  26. >Wrong.
  27. >
  28. >>The rationale document for ANSI C explicitly
  29. >>recognizes the optimization penalty inherent in pointers and suggests
  30. >>that remedies to this be a priority in future versions of the standard.
  31. >>Yes, if avoid procedure calls (at least, all those whose arguments
  32. >>are pointers), 
  33. >
  34. >Automatic optimization by compilers have little to do with the above
  35. >mentioned *HAND* optimization.
  36. >
  37. >You can transform the following program
  38. >
  39. >       f(a,b,c)
  40. >       double *a,*b,*c;
  41. >
  42. >       for(i=0;i<4*N;i++)
  43. >       {    a[i]+=b[i]*c[i];
  44. >           ...
  45. >
  46. >to
  47. >
  48. >       for(i=0;i<N;i+=4)
  49. >       {    b0=b[i]; b1=b[i+1]; b2=b[i+2]; b3=b[i+3];
  50. >           c0=c[i]; c1=c[i+1]; c2=c[i+2]; c3=c[i+3];
  51. >           a0=a[i]; a1=a[i+1]; a2=a[i+2]; a3=a[i+3];
  52. >           a[i]=a0+b0*c0; ...
  53. >
  54. >by hand, knowing that the area for a, b and c does not overlap.
  55.  
  56. Thank you:  you are providing an excellent example of why
  57. Preston is right:
  58.  
  59. (1) The optimization you just performed is machine specific: the optimal
  60. amount of loop unrolling depends on the precise characteristics of
  61. your hardware and may even differ from workstation to workstation of
  62. the same type.
  63.  
  64. (2) You just introduced two serious bugs.
  65.  
  66. (3) Finally, you cheated. Usually, limits don't work out that nicely
  67. (even if you get them right) so that you need special case code (e.g.,
  68. Duff's device) to handle the special cases.
  69.  
  70. There are a few cases where hand optimizations like these are
  71. justified in C (e.g., the X11 blitter code). But don't fool yourself
  72. and others into believing that they are "easy" or "portable".
  73.  
  74. Some problems with C pointers are fixable with a "noalias"
  75. declaration, so the situation may get slightly better. But,
  76. ultimately, C is a poorly designed language for truly aggressive
  77. optimization and high-performance computation, even if you are willing
  78. to do a lot of work by hand.
  79.  
  80.                     Thomas.
  81.  
  82. PS: I still use C/C++ for much of my work, because usually
  83. pragmatic issues like interfacing with existing libraries are
  84. more important to me than getting the best optimizations.
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.