home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1666 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.5 KB
  1. Xref: sparky comp.edu:1666 comp.lang.fortran:3562 comp.lang.misc:3083 comp.arch:9426 sci.math:11484
  2. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  3. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel
  4. From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
  5. Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
  6. Message-ID: <1992Sep15.154932.5907@alchemy.chem.utoronto.ca>
  7. Followup-To: comp.lang.misc
  8. Organization: Department of Chemistry, University of Toronto
  9. References: <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de> <mcdonald.299@aries.scs.uiuc.edu> <9225915.145@mulga.cs.mu.OZ.AU>
  10. Distribution: na
  11. Date: Tue, 15 Sep 1992 15:49:32 GMT
  12. Lines: 37
  13.  
  14.  
  15. Note that I have redirected followups to comp.lang.misc.  I fail to see
  16. the relevance of this discussion to the other newsgroups mentioned;
  17. certainly it has little to do with mathematics.
  18.  
  19. In article <9225915.145@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
  20. (Fergus James HENDERSON) writes:
  21. >mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
  22. >>kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
  23. >>>Take Pascal-XSC. It is available on all unix machines since it compiles to
  24. >>>standard C. It allows users to define operators monadic and dyadic, and it
  25. >>>comes with many of them for interval, vector, matrix, complex etc.
  26. >>>computations.
  27. >>
  28. >>However, the results will be no faster .... and almost surely slower,
  29. >>than simply coding in C.
  30. >
  31. >Why "almost surely slower" than C?
  32.  
  33.      Automatic source translation to a high-level language almost never
  34. generates code that a human would have written.  Since compilers and
  35. optimizers are tested almost entirely with human-written code, it is
  36. very likely that machine-translated code will break optimizer
  37. assumptions.  At best, this means that the code will run more slowly
  38. than a program written directly in the eventual compilation language; at
  39. worst, this exposes compiler and optimizer bugs which a compiler vendor
  40. will be reluctant to look at due to the obtuseness of the code.
  41.      For an example of this sort of thing, consult the June 1992 issue
  42. of the Hewlett-Packard journal.  Their Fortran optimizing preprocessor
  43. (which does Fortran->Fortran source translation) uncovered some bugs in
  44. both the compiler front end and in the optimizer for the reasons stated
  45. above.
  46.  
  47.                                 Sincerely,
  48.  
  49.                 Marc R. Roussel
  50.                                 mroussel@alchemy.chem.utoronto.ca
  51.