home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10490 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  5.7 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!exodus.Eng.Sun.COM!news
  2. From: gordoni@lunarbase.cs.adelaide.edu.au (Gordon Irlam)
  3. Newsgroups: comp.arch
  4. Subject: Re: SPA: pixie for Sparc architecture
  5. Date: 7 Nov 1992 00:56:51 GMT
  6. Organization: Sun Microsystems Inc., Mountain View, CA
  7. Lines: 121
  8. Message-ID: <lfm52jINNkj6@exodus.Eng.Sun.COM>
  9. References: <Bx8yAw.FF4@dcs.glasgow.ac.uk>
  10. Reply-To: gordoni@cs.adelaide.edu.au
  11. NNTP-Posting-Host: lunarbase
  12.  
  13. > That seems to be some kind of AI planning system -- certainly not a trace
  14. > generator!  If anyone can tell where this really lives, I'd be grateful...
  15.  
  16. Spa is a set of tools used to analyze the performance of SPARC
  17. binaries on the SPARCstation 1 and the SPARCstation 2.  The tools can
  18. be used on any sun4 architecture machine running a SunOS 4 operating
  19. system.
  20.  
  21. The tools include spy a program that traces the execution of a command
  22. and can generate address traces, spanner a tool that converts an
  23. address trace into an instruction count, splice a tool that combines
  24. instruction count files, and spout a tool that displays an instruction
  25. count file.
  26.  
  27. No modification of the binary to be analyzed is required.  Dynamic
  28. libraries, job control, and fork/exec are all handled correctly.  Some
  29. signal handlers may cause problems.
  30.  
  31. The Spa package does not predict overall system performance.  I/O
  32. latency is not taken into consideration, nor is the effect of more
  33. than one process being active at any one time.  spy does not provide
  34. any information about the time spent handling traps, interrupts, or
  35. system calls, nor the effects of these on the cache.
  36.  
  37. The floating point queue is not currently simulated by the Spa
  38. package, and all floating point instructions are assumed to complete
  39. in a single cycle.  This differs significantly from reality.
  40.  
  41. The main component of the Spa package is a SPARC simulator.  A basic
  42. block style profiling tool is not currently included.  Consequently
  43. the speed of this package is roughly 600 times slower than normal
  44. execution.
  45.  
  46. The Spa package is a copyrighted work which comes with absolutely no
  47. warranty.  It may be redistributed and/or modified under the terms of
  48. the GNU General Public License Version 2 as published by the Free
  49. Software Foundation.
  50.  
  51. The Spa package is available from the following locations,
  52.  
  53.     U.S. FTP:         ftp.uu.net:/systems/sun/spa-1.0.tar.Z
  54.     U.S. UUCP:        uunet!~/systems/sun/spa-1.0.tar.Z
  55.     Australia FTP:    ftp.cs.adelaide.edu.au:pub/sparc/spa-1.0.tar.Z
  56.  
  57. You should also get spa.diff-1.0-1.01.Z from the same location.  This
  58. fixes a minor bug.
  59.  
  60. If you plan to hack Spa you might want to get spa-unstable.tar.Z from the
  61. Australian site.  See the README file therein to find out why.
  62.  
  63. ---------------------------------------------------------------------
  64.  
  65. You might also be interested in spix/shadow developed by Bob Cmelik
  66. of Sun Microsystems.  This is closer to pixie in that it rewrites
  67. the binary.  Spa currently simulates each instruction.  Consequently
  68. spix is much faster, but has difficulty handling dynamic libaries.
  69.  
  70. Contact rfc@sun.com to order spix/shadow.  There is no charge, but
  71. you are required to sign (in ink) a license agreeing not to sue Sun
  72. if anything goes wrong.
  73.  
  74. ---------------------------------------------------------------------
  75.  
  76. Tools for SPARC performance analysing:
  77.  
  78. prof(1).  Included as part of Sun C?
  79.   - Requires source for sections to be profiled.
  80.   - Displays number of times each routine to be profiled is called, and
  81.     profil(2) based execution time estimates.
  82.   - Compiler adds code to count routines and call to profil(2).
  83.  
  84. gprof(1).  Included as part of Sun C.
  85.   - Requires source for sections to be profiled.
  86.   - Displays number of times each routine to be profiled is called, and
  87.     profil(2) based execution time estimates.
  88.   - Compiler adds code to count routines and call to profil(2).
  89.  
  90. tcov(1).  Included as part of Sun C.
  91.   - Requires source files to be profiled.
  92.   - Displays number of times each source line in the files to be profiled
  93.     is executed.
  94.   - Compiler adds basic block counting information to the object files.
  95.  
  96. GNU versions of prof/gprof/tcov are also being developed.
  97.  
  98. Spa (gordoni@cs.adelaide.edu.au). 
  99.   - Requires a 4.x binary.
  100.   - Displays architectural simulation information.
  101.   - Simulates instructions in-situ by using delayed control transfer couples.
  102.     Passes an address trace to an analyser.
  103.  
  104. spix by Bob Cmelik (rfc@sun.com).
  105.   - Requires a statically linked 4.x binary.
  106.   - Displays architectural simulation information.
  107.   - Rewrites and instruments basic blocks.
  108.  
  109. A comprehensive set of simulation tools by James Larus (larus@cs.wisc.edu).
  110. Early versions used to be available for free, but I think this is no longer
  111. the case.
  112.  
  113. SPARCsim (contact jting@Corp.Sun.Com).  This is a heavy weight SPARC
  114. simulator that includes some performance analysis tools.  Expensive.
  115. Can't handle fork/exec.  Not recommended for typical performance analysis
  116. tasks.
  117.   - Requires binary to be profiled.  Must be statically linked.
  118.   - Displays instruction and cycle count data.
  119.   - Analyzes an address trace produced by a simulator.
  120.  
  121. DSIC by David Cook (contact grossman@cs.clemson.edu).  This is a Cypress
  122. pipeline simulator.
  123.   - Requires assembly code for sections to be profiled.
  124.   - Displays instruction count data for sections to be profiled.
  125.   - Program munges assembly code to add basic block counting information.
  126.  
  127. Iprof by Steve Reiss (spr@cs.brown.edu) an instruction counting simulator.
  128.   - Requires startup object file.  Must link statically.
  129.   - Displays number of times each routine is called, and number of
  130.     instructions exected by that routine, for all routines.
  131.   - Add call to IPROFstart at start of code.  This routine rewrites the
  132.     binary so that basic block information is gathered.
  133.  
  134.