home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8297 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.7 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!mash
  2. From: mash@mips.com (John Mashey)
  3. Newsgroups: comp.arch
  4. Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
  5. Date: 24 Jul 1992 23:04:22 GMT
  6. Organization: MIPS Computer Systems, Inc.
  7. Lines: 56
  8. Message-ID: <l7133mINN75s@spim.mips.com>
  9. References: <9207160336.AA02067@x1sun6.ccl.itri.org.tw> <GLEW.92Jul23181843@pdx007.intel.com>
  10. NNTP-Posting-Host: winchester.mips.com
  11.  
  12. In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
  13. >    Maybe true. But for a user, should he buy one $2000 21064 chip or another
  14. >    two $1000 CY7C601!?
  15. >
  16. >This is a rather bogus discussion.
  17. ....
  18.  
  19. Yes:
  20. 1) For many applications, one will happily leave them as 32-bit applications,
  21. because they'll probably run faster in 32-bit model, so why mess with
  22. them?
  23.  
  24. 2) A few applications exist where pushing 64-bit integers around
  25. conveniently might have good gains, either due to 64x64->128
  26. multiplies, or just puhsing data 2X faster conveniently.
  27.  
  28. 3) The main reason is to get more address sapce (conveniently).
  29. There are not a *huge* number of these things; however, the ones that
  30. are there are *extremely* important to the people who use them, as they
  31. are things like:
  32.     1) Scientific codes
  33.         "Goody; we expand our FORTRAN arrays by factor of 10"
  34.     2) Some ECAD programs
  35.         "Goody, we can still simulate the R11000 after all"
  36.     3) Some MCAD programs
  37.         "Great, we can simulate the 199x automobile in one piece."
  38.     4) Video& animation
  39.         "Great, let's get put Terminator 6 in memory for editing"
  40.     5) Financial
  41.         "Good, we can finally put the financial model of the US
  42.         in memory and grep around in it at speed."
  43.     6) DBMS
  44.         "Good, we can map 4 whole 1GB SCSI disks into memory at once",
  45.         i.e., disks that fit in a desktop box.
  46.     7) CASE
  47.         "Thank goodness, there's still space for the new EMACS" :-)
  48.  
  49. o
  50. >    Some of the applications I will want to use in a few years
  51. >    will undoubtedly run faster (or, more likely, be easier to code)
  52. >    because of 64 bits -- like the oft-awaited global flat namespace.
  53. >    But I won't hold my breath (at least not until ISDN).
  54.  
  55. Each to their own; fortunately for us, plenty of people want this
  56. in 1993.  I'd guess the "just recompile this FORTRAN program bigger"
  57. cases will get there quickest.
  58.  
  59. As I've noted several times before, having 64-bit integers cost
  60. something like 5% of the die space, so it's not a big deal.
  61. Certainly, a 64-bit chip doesn't automatically (or even usually)
  62. go 2X faster than a 32-bit chip.
  63. -- 
  64. -john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
  65. UUCP:      mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
  66. DDD:      408-524-7015,  or 524-8253
  67. USPS:    (soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
  68.