home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / fortran / 4340 < prev    next >
Encoding:
Text File  |  1992-11-17  |  4.5 KB  |  90 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!draco.macsch.com!convex.is.macsch.com!dnl
  3. From: dnl@convex.is.macsch.com (David Lombard)
  4. Subject: Re: Fortran to C issues?
  5. Message-ID: <1992Nov17.224350.26781@draco.macsch.com>
  6. Sender: usenet@draco.macsch.com (Usenet Poster)
  7. Organization: MacNeal-Schwendler Corp.
  8. References: <BxtKJL.2Ir@accelr8.com>
  9. Date: Tue, 17 Nov 92 22:43:50 GMT
  10. Lines: 78
  11.  
  12. In article <BxtKJL.2Ir@accelr8.com> jim@accelr8.com (Jim Reiss) writes:
  13. >In some computation-intensive environments there seems to be a general
  14. >feeling that FORTRAN is much better than C for some tasks.  I shudder to
  15. >be asking this because rekindling the C/FORTRAN flame war is not what
  16. >I want to do...but...is there a good basis for that opinion, and does that
  17. >mean that FORTRAN to C translators like f2c and the NAG FORTRAN compiler
  18. >are inherently inferior to a FORTRAN to machine language compiler?  If so,
  19. >please explain why.  Please try to keep answers from degenerating into
  20. >"so there" and religious style comments.  Thank you.
  21. >-- 
  22.  
  23. One reason has to do with the compiler's ability to *understand* the
  24. code and its ability to optmize.  As an example, Fortran specifically
  25. _prohibits_ more than a single argument to a subroutine to *define*
  26. a value (i.e. equivalence associations may not occur through the
  27. argument list).  The compiler is then able to gain additional information
  28. about the code.  C relies very heavily on pointers which could point to
  29. anything, thus the complier can glean (glomm?) much less information
  30. about the code, so some optimization will, at very least, _appear_ to
  31. be unsafe.  Glancing at a *typical* (what's that?!?) C function, one often
  32. sees more than one pointer to the same location being used in different
  33. contexts.  Some C compilers admit command line options or #pragma's to
  34. allow the programmer to provide such hints.
  35.  
  36. Another (historical) reason had to do with the K&R definition of C 
  37. that demanded *implicit* promotions in argument lists and required 
  38. float operations to be done in double mode.  If you're only doing an 
  39. occasional float operation, what's the big deal?  But, try writing a 
  40. single-precision (half-precision?) matrix utility, and you can 
  41. imagine the performance hits.  Fortunately, ANSI did away with that 
  42. particular thought pattern when function prototypes are used.  Always
  43. Prototype!
  44.  
  45. Next, there is the problem of passing multi-dimensioned, assumed-size
  46. arrays, C doesn't!  While there are many, games you can play to deal
  47. with the issue (see in particular "Numerical Recipes in C"), it's
  48. still a nuisance.
  49.  
  50. Finally, and this will change with time, Fortran compiler writers have
  51. more experience in highly optimized code than do C compiler
  52. writers.  That's a temporary advantage at best.
  53.  
  54. On C's side, have you ever seen code which dealt with bitmaps, free
  55. memory chains, complicated structures and the like in Fortran?  Talk
  56. about terminally ugly and begging for coding errors!
  57.  
  58. So, the *best* language depends on what your needs are!  The choice
  59. of *best* need not be a single value for a given project.  Depending
  60. upon what the application is, I will argue for anything from _pure_
  61. Fortran, to a mix of Fortran and C, to _pure_ C!
  62.  
  63. Now for things like f2c, the NAG F90 and Vienna Fortran compilers (this 
  64. also applies to C++ when implemented as a font-end to a C compiler).  
  65. These systems insert another layer of translation between the 
  66. programmer's original source and the target (i.e. machine language).  
  67. Clearly the front-end compiler can obscure the original code and 
  68. introduce additional constructs which may degrade optimization.
  69. How much the code is degraded depends upon how much effort 
  70. the authors of the higher-level compiler put in to understanding the 
  71. requirements of the target compiler.  To be fair, the higher-level
  72. compiler writers could also enhance performance by performing analysis
  73. which the target compiler _should_ have performed, but didn't!
  74.  
  75. Please do not misunderstand me, there _is_ a place for these systems
  76. too, but I wouldn't want to compete against a good (maybe even
  77. mediocre in some instances) native compiler.
  78.  
  79. So, as in all things, there are not absolutes!  You must evaluate _your_
  80. requirements and somehow match these to the options available to _you_.
  81.  
  82. Regards,
  83. DNL
  84.  
  85.                  MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES
  86.  
  87. David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
  88. dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
  89. (213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
  90.