home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16464 < prev    next >
Encoding:
Text File  |  1992-11-14  |  2.8 KB  |  63 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Reasons for using C vs. Fortran or vice/versa
  5. Message-ID: <1992Nov13.171542.10650@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <1992Nov12.135901.15191@ccd.harris.com> <1992Nov12.210151.5486@alchemy.chem.utoronto.ca>
  8. Distribution: usa
  9. Date: Fri, 13 Nov 1992 17:15:42 GMT
  10. Lines: 51
  11.  
  12. mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
  13.  
  14. >     It is easier to write Fortran that a compiler will properly optimize
  15. >than it is to write optimizable C.  One chap at HP has a trivial routine
  16. >that the Fortran optimizing compiler immediately recognizes and does the
  17. >right thing with, but which needs to be heavily modified to obtain good
  18. >performance in its C version.
  19.  
  20. This is a trifle ingenuous, or perhaps just incomplete.
  21.  
  22. Historically, Fortran was an unstructured language.  To get reasonable
  23. performance, compilers did extensive flow analysis and performed
  24. extensive optimization.  Fortran was run on big machines, and
  25. compilers could take the time and space to do the analysis.  This
  26. tradition of optimization has been carried forward to the present.
  27.  
  28. Historically, C was a structured language developed on and for small
  29. machines.  Flow analysis was less necessary, and typical machines
  30. were not suitable for large and complex compilers.  Further, the
  31. nature of C and C programming styles made optimization less of a
  32. win (see below).  In recent years, C compilers have begun to do more
  33. optimization.
  34.  
  35. There are, however, language features which lead to fewer opportunities
  36. for optimization in C than in Fortran.  Fortran doesn't use pointers
  37. the way C does.  Fortran arrays, for example, are first-class objects,
  38. not converted to pointers as in C.  If a C routine uses pointers, the
  39. compiler typically has no way of knowing what any of them point to.
  40. It cannot make simplifying assumptions as in Fortran, since any time
  41. a value is stored through a pointer, the compiler must assume that
  42. almost ANY data value might have been changed.  Example:
  43.     extern double x, y, z;
  44.     void foo(double p[], double q[], int i)
  45.     {
  46.         p[i] = x + y;
  47.         z = x + y + q[i];
  48.     }
  49. Inside foo, p and q might point to the same object, and might point
  50. to x, y, or z.  The first line might have changed the value of x or y,
  51. for example, so the compiler must reload the values of x and y for the
  52. second line, rather than using the remembered sum.  This is the
  53. "aliasing" problem, and dramatically affects the efficiency of
  54. mathematical code in C compared to Fortran.
  55.  
  56. With the equivalent Fortran code, the subroutine would have array
  57. parameters, and the compiler could assume that the arrays were
  58. disjoint from the global variables x, y, and z.
  59. -- 
  60.  
  61. Steve Clamage, TauMetric Corp, steve@taumet.com
  62. Vice Chair, ANSI C++ Committee, X3J16
  63.