home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / benchmar / 1729 < prev    next >
Encoding:
Text File  |  1992-11-18  |  1.6 KB  |  32 lines
  1. Newsgroups: comp.benchmarks
  2. Path: sparky!uunet!metaflow!rschnapp
  3. From: rschnapp@metaflow.com (Russ Schnapp)
  4. Subject: Re: DEC ALPHA Performance Claims
  5. Message-ID: <BxxwF1.D7q@metaflow.com>
  6. Sender: usenet@metaflow.com
  7. Nntp-Posting-Host: habu
  8. Organization: Metaflow Technologies Inc.
  9. References: <BxH7s7.5Cv@inews.Intel.COM> <4248@bcstec.ca.boeing.com> <BxuCsv.FwE@pix.com> <willmore.722118562@help.cc.iastate.edu>
  10. Date: Thu, 19 Nov 1992 01:35:25 GMT
  11. Lines: 19
  12.  
  13. In article <willmore.722118562@help.cc.iastate.edu>, willmore@iastate.edu (David Willmore) writes:
  14. |> I don't expect that will be much of a problem with the Alpha.  From the way the 
  15. |> archetecture is designed, it looks like the most optimization and ordering takes
  16. |> place on-chip.  The compiler orders things in a fairly general way which the CPU
  17. |> schedules.  I wouldn't say that Alpha eliminates all code ordering problems, but
  18. |> it should be less effected than other archetectures.  At least I hope so.
  19. -- 
  20.  
  21. Are you sure you're talking about the 21064 implementation of Alpha?  I
  22. believe it's a very vanilla superscalar implementation (kind of an
  23. oxymoron at this point, huh?).  It doesn't do any of that far-out,
  24. register-renaming, out-of-order stuff, as far as I know.  Now, I do
  25. know of another architecture that will do all this stuff, but I don't
  26. want to be too self-serving here...     8-)
  27.  
  28. ...Russ Schnapp
  29. BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
  30. Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
  31. La Jolla, California    Unless otw specified, I`m speaking only for myself!
  32.