home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / fortran / 5134 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.4 KB  |  51 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uimrl7.mrl.uiuc.edu!ercolessi
  3. From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
  4. Subject: Compiler groups working on real apps? (was Re: Fast I/O)
  5. References: <1jhqkhINNno3@bigboote.WPI.EDU> <1993Jan21.081105.4047@molene.ifremer.fr> <1993Jan22.193019.12936@news.eng.convex.com>
  6. Message-ID: <C19wHr.GF3@news.cso.uiuc.edu>
  7. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  8. Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
  9. Organization: MRL - UIUC
  10. Date: Fri, 22 Jan 1993 20:49:03 GMT
  11. Lines: 38
  12.  
  13. In article <1993Jan22.193019.12936@news.eng.convex.com>, Patrick F. McGehearty <patrick@convex.COM>
  14. writes:
  15. |>[...]  There are always more
  16. |>potential optimizations and features to add to a language like Fortran
  17. |>than there are resources to add them (Fortran 90 makes this statement
  18. |>self-evident :-).  If a compiler group has been entirely driven by the old
  19. |>simple benchmarks such as Whetstones, Dhrystones, and Linpack 100x100, 
  20. |>they will not even realize that there is a worthwhile optimization to be
  21. |>made in this case.  If they use real production applications, then the
  22. |>optimization may get on their to-do list, depending on their target market
  23. |>segment. 
  24.  
  25. Hmmm.  Do you mean that compiler developers may have the resources
  26. to deal with masses of strange, horrible codes written or used by all
  27. the folks out here? To analyze these codes and see where they spend time?
  28.  
  29. This is probably too much to ask.  But I am wondering.  Maybe any one of
  30. us (users) could spend some time in putting together some "typical" code,
  31. containing a simplified version of the loops where our programs spend
  32. most of the time.  Staying within, say, 100 lines.  These "test cases" could 
  33. be posted on c.l.f. (and stored at some anon ftp site) and compiler developers 
  34. could have a look at them and perhaps improve the compilers.
  35.  
  36. These typical loops could perhaps also be coded as self-contained
  37. benchmarks a-la-Linpack, inducing a bit of competitiveness :-), 
  38. helping us to understand better the strengths and weaknesses of the
  39. various architectures, but not necessarily so.
  40.  
  41. Any comment?
  42.  
  43. furio
  44. --
  45. furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
  46. * materials research lab, uni illinois at urbana-champaign
  47. + intl school for advanced studies, trieste, italy   
  48.  
  49. "Change nothing and continue with immaculate consistency"
  50.                                       [ Brian Eno, "Oblique Strategies" ]
  51.