home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 11009 < prev    next >
Encoding:
Text File  |  1992-11-22  |  1.5 KB  |  40 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!stanford.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jfc
  3. From: jfc@athena.mit.edu (John F Carr)
  4. Subject: Re: DEC Alpha AXP System INTEGER Performance
  5. Message-ID: <1992Nov22.170912.26878@athena.mit.edu>
  6. Keywords: Alpha, AXP, SPEC, DEC, INTEGER
  7. Sender: news@athena.mit.edu (News system)
  8. Nntp-Posting-Host: achates.mit.edu
  9. Organization: Massachusetts Institute of Technology
  10. References: <1698@niktow.canisius.edu> <jdd.721687838@cdf.toronto.edu> <1992Nov20.220615.7494@raid.dell.com>
  11. Date: Sun, 22 Nov 1992 17:09:12 GMT
  12. Lines: 26
  13.  
  14. In article <1992Nov20.220615.7494@raid.dell.com>
  15.     samf@yosemite.dell.com (Sam Fuller) writes:
  16.  
  17. >After reviewing the Alpha performance claims, I had the feeling that the
  18. >integer unit did not really run at 133Mhz.  It looked to me that the
  19. >floating point pipeline was superpipelined at 133Mhz, but that the integer
  20. >side ran at a more reasonable 66Mhz.  The pipes can operate independently
  21. >and I imagine be dispatched in parallel, hence the superscalar appelation.
  22.  
  23. The integer pipeline runs at full speed, but:
  24.  
  25.     . dual issue is rare in the current implementation with current
  26.     compilers, for integer-only code
  27.  
  28.     . many instructions, including load and shift, have multi-cycle
  29.     latencies
  30.  
  31.     . the primary caches are small and the secondary cache has a
  32.     long access time
  33.  
  34. gcc in particular runs slowly on an Alpha, because it uses a lot of bit
  35. manipulation instructions, makes many memory references, and has a poor
  36. memory access pattern.
  37.  
  38. --
  39.     John Carr (jfc@athena.mit.edu)
  40.