home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.18 / text0037.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  4.4 KB
  1. From: rnovak@mips.COM (Robert E. Novak)
  2.  
  3. As promised here is a list of criteria to look at when considering a
  4. program to be submitted to SPEC for consideration as an application
  5. benchmark.  This is not intended to be an exhaustive list, in fact it is
  6. only this author's opinions.  This list has not been 'blessed' by the SPEC
  7. steering committee.  If your program does not meet on all criteria, it
  8. doesn't mean an automatic rejection, it just depends on how much work we
  9. need to do to make it acceptable and how appealing your application is to
  10. SPEC.  After your program has been submitted as a candidate program, the
  11. Steering Committee will need to find a sponsor (a Steering Committee
  12. member) and a project leader (who will actually do the work).
  13.  
  14. Submit Permission forms and/or programs to one of the following:
  15. rnovak@mips.com, shanley@cup.portal.com.  We will reply ASAP (remember that
  16. next week is UniForum).  Include e-mail, U.S. Mail telephone and FAX
  17. numbers as applicable or possible.  To request a more information on SPEC,
  18. call 1-415-792-2901.
  19.  
  20. Criteria
  21.  
  22.          1.  The program should be an application-oriented program,
  23.              i.e. a program that is frequently used by an active
  24.              user community.
  25.  
  26.          2.  Each program must be a key component in a long-range
  27.              goal to test overall processor/system performance.
  28.              SPEC wants to exhaustively exercise not only the CPU
  29.              and FPU, but also the Disk I/O, Tape I/O and Network
  30.              I/O as well as the operating system scheduler.
  31.  
  32.          3.  Each program must be a representative component in a
  33.              wide-range of applications.  SPEC wants representative
  34.              programs from scientific (CAD, ECAD, MCAD, Seismic,
  35.              Nuclear Physics, Astronomy, etc.), Technical (CASE,
  36.              compilers, CPU simulators, debuggers, software
  37.              development aids, etc.) and commercial applications
  38.              (Accounts Receivable, MRP, ISAM files, RDBMS based MIS
  39.              applications, flight scheduling programs, distribution
  40.              routing (trucking, railroads), etc.).
  41.  
  42.          4.  Each program should be large, in terms of total
  43.              program size, size of most compute-intensive block and
  44.              in terms of the total working set size of both the
  45.              instruction set and the data reference set.
  46.  
  47.              All too many performance tests have squeezed into on
  48.              board CPU caches, which may not be representative of
  49.              actual applications.
  50.  
  51.          5.  The programs should be long-running programs (greater
  52.              than 60 seconds of execution time on a 10 mip CPU).
  53.              Programs that use less CPU time than that will result
  54.              in measurements that are below the resolution of
  55.              system timer programs.  In addition, these
  56.              applications for performance testing will hopefully
  57.              have a lifetime that exceed 18 months of meaningful
  58.              duty.
  59.  
  60.          6.  Whenever possible, the program should be public domain
  61.              or it should be made publicly available under the SPEC
  62.              license umbrella.  This is the part that makes the
  63.              SPEC job the hardest.  A software developer must be
  64.              willing to allow the competition to examine at least
  65.              some part of their source code in order to make the
  66.              code available to SPEC.
  67.  
  68.          7.  The program must be easily portable to many machines.
  69.              A program that is developed for the UNIX (R)
  70.              environment is usually the simplest to port to most
  71.              platforms.
  72.  
  73.          8.  The program's output must be mechanically checkable
  74.              for correctness.  The benchmarks are useless unless we
  75.              can verify that they produce identical results.
  76.  
  77.          9.  The programs' source code should conform to existing
  78.              language standards for the implementation language.
  79.              In attempting to move the SPEC benchmarks from 32 bit
  80.              platforms to 64 bit platforms, SPEC has discovered
  81.              that this was the greatest sin in Release 1.0.
  82.  
  83. -- 
  84. Robert E. Novak                                     MIPS Computer Systems, Inc.
  85. {ames,decwrl,pyramid}!mips!rnovak      928 E. Arques Ave.  Sunnyvale, CA  94086
  86. rnovak@mips.COM       (rnovak%mips.COM@ames.arc.nasa.gov)       +1 408 991-0402
  87.  
  88. Volume-Number: Volume 18, Number 38
  89.  
  90.