home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / fortran / 5167 < prev    next >
Encoding:
Text File  |  1993-01-25  |  3.3 KB  |  63 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!convex!convex!patrick
  3. From: Patrick F. McGehearty <patrick@convex.COM>
  4. Subject: Re: Compiler groups working on real apps?
  5. Originator: patrick@wagner.convex.com
  6. Sender: usenet@news.eng.convex.com (news access account)
  7. Message-ID: <1993Jan25.171227.10633@news.eng.convex.com>
  8. Date: Mon, 25 Jan 1993 17:12:27 GMT
  9. Reply-To: patrick@convex.COM (Patrick F. McGehearty)
  10. References: <C19wHr.GF3@news.cso.uiuc.edu> <1993Jan23.003639.13681@craycos.com> <C1Cnq5.1zt@news.cso.uiuc.edu>
  11. Nntp-Posting-Host: wagner.convex.com
  12. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  13. X-Disclaimer: This message was written by a user at CONVEX Computer
  14.               Corp. The opinions expressed are those of the user and
  15.               not necessarily those of CONVEX.
  16. Lines: 45
  17.  
  18. In article <C1Cnq5.1zt@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
  19. ...comments suggesting that Livermore Loops do not contain interesting
  20. ...representatives of his type of applications (classical molecular
  21. ...dynamics), partly due to lack of use of the indirect addressing
  22. ...coding technique.
  23.  
  24. I consider the Livermore Loops a necessary but not sufficient test of
  25. compiler code generation quality.  I suspect one reason why it does not
  26. contain much indirect addressing is that most codes from which the loops
  27. were selected were developed in the 1970's and before.  Architectures
  28. were different, problem sizes were smaller, etc, etc.  At time passed
  29. we (the computing community) evolve different approaches, so our commonly
  30. used benchmarks need to evolve and expand also.  I would welcome some
  31. meaningful kernel benchmarks of indirect addressing.
  32.  
  33. Ideally, such a benchmark would contain:
  34. 1) Source code in reasonably portable Fortran (so we are all looking at the
  35. same thing)
  36. 2) Information about whether the different elements of the indirectly
  37. addressed arrays are independent (very important for adding compiler
  38. directives to allow vector or parallel execution.
  39. 3) Several data sets for evaluating the benchmark
  40.   The data sets should have the following characteristics
  41.   a) A small data set which executes quickly on the slowest machine the
  42.     application is interested in (say a second or two on a current 20
  43.     Mips, 20 Mflops box)
  44.     This data set is useful to the compiler developers for basic correctness
  45.     testing, and for the architectural simulator people for studying new
  46.     architectures.
  47.   b) A medium data set which executes in not more than a few hours on the
  48.     slowest machine of interest.
  49.   c) A large data set which is large enough to properly stress architectural
  50.     features such as cache, large numbers of processors, communication
  51.     latencies, etc, etc.
  52. For an indirect addressing benchmark particularly, the pattern of memory
  53. accesses should fairly represent production environment data sets so future
  54. systems will be tuning to maximize real data sets, not some artifically
  55. simplified data set.  An extreme example of a bad data set would be one
  56. where each indirect address was at a successive location in memory.
  57.  
  58. I understand the Perfect Group is actively seeking such benchmarks.
  59. If they adopt a benchmark and put it in their suite, it will gain instant
  60. credibility with a number of vendors.  For contact info on the Perfect
  61. Group, see the FAQ in comp.benchmarks.
  62.  
  63.