home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8271 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  2.5 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  2. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  3. Newsgroups: comp.arch
  4. Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
  5. Message-ID: <54990@mentor.cc.purdue.edu>
  6. Date: 24 Jul 92 13:27:59 GMT
  7. References: <9207160336.AA02067@x1sun6.ccl.itri.org.tw> <GLEW.92Jul23181843@pdx007.intel.com>
  8. Sender: news@mentor.cc.purdue.edu
  9. Organization: Purdue University Statistics Department
  10. Lines: 44
  11.  
  12. In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
  13.  
  14. >    Maybe true. But for a user, should he buy one $2000 21064 chip or another
  15. >    two $1000 CY7C601!?
  16.  
  17. >This is a rather bogus discussion.
  18.  
  19. >The assumption seems to be implicit that, given the same technology,
  20. >etc., a 64 bit architecture implies twice the performance of a 32 bit
  21. >architecture.
  22.  
  23. >That's blatantly untrue, since the overwhelming majority of applications
  24. >fit quite nicely into 32 bit address and data quantities, so from this
  25. >point of view 32 = 64.
  26.  
  27. Of course it is blatantly untrue, unless you can do the 64-bit operations
  28. and accesses as fast as 32 bit ones.  On at least one machine I am now
  29. using, nobody should ever use the "single precision" (really half
  30. precision) floating point arithmetic, because the hardware always
  31. converts to double and then back, unless memory is at a drastic premium.
  32.  
  33. >There may be some applications that can benefit from >32 bit virtual
  34. >addresses, e.g. the 40 bit virtual addresses of the MIPS R4000. I'm
  35. >tempted to say that this implies 32 = 4/5 40, but of course there is
  36. >overhead in evaluating extended precision arithmetic. The overhead may
  37. >be more than 2x.  But then you have to downgrade that by the ratio of
  38. >time spent manipulating such addresses.
  39.  
  40. >Finally, there are some applications that benefit from simply having
  41. >larger integers.  John Mashey has mentioned robotics as one such area
  42. >(although I have talked to robotics manufacturers who take a
  43. >completely different approach). But, once again, you have to prorate
  44. >the speedup according to the importance of the code being executed.
  45.  
  46. It is clear that you do not do any type of "honest" integer arithmetic,
  47. or you could not possibly take this view.  
  48.  
  49. It would be rare indeed for a 32-bit machine to be able to do 64-bit
  50. arithmetic at anywhere near the speed of a 64-bit machine.
  51. -- 
  52. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  53. Phone: (317)494-6054
  54. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  55. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  56.