home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12085 < prev    next >
Encoding:
Text File  |  1993-01-05  |  3.3 KB  |  84 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!moo!awolfe
  3. From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
  4. Subject: Re: FP-number cache? Unclocked VLSI design.
  5. Message-ID: <1993Jan5.170446.15655@Princeton.EDU>
  6. Originator: news@nimaster
  7. Sender: news@Princeton.EDU (USENET News System)
  8. Nntp-Posting-Host: moo.princeton.edu
  9. Organization: Princeton University
  10. References:  <1993Jan5.085415.19676@klaava.Helsinki.FI>
  11. Date: Tue, 5 Jan 1993 17:04:46 GMT
  12. Lines: 70
  13.  
  14. In article <1993Jan5.085415.19676@klaava.Helsinki.FI>, veijalai@klaava.Helsinki.FI (Tony Veijalainen) writes:
  15. ...
  16. |> 
  17. |> On the other hand FPU-units that appear more and more are in modern big
  18. |> CPU:s are quite far conceptually from other operations.  I have
  19. |> suspision that FP-arithmetic tends to cluster quite heavily, and because
  20. |> of traditional efficiency thinking and fixed number arithmetic in
  21. |> business applications some big parts of programs are integer only (not
  22. |> much FP-operations in interupt code for example :-). 
  23. |> 
  24. |> So have somebody researched the havoc FPU-instructions make to general
  25. |> data cache? Is there possible advantage of having FP-number (with
  26. |> separate bus to FPU-register file) and fixnumber caches with advantages
  27. |> outdoing the cost on CPU (like diminiching the general cache size, is
  28. |> this over specialization?). 
  29. |> 
  30. |> -- 
  31. |> Tony Veijalainen    e-Mail: Tony.Veijalainen@helsinki.fi (preferred)
  32. |>          (finger veijalai@plootu.helsinki.fi for more information)
  33. |> 
  34.  
  35.  
  36. My students and I performed this experiment last year.  I thought that it
  37. was a great idea.  In retrospect - maybe it wasn't.
  38.  
  39. The idea was this:
  40. -------------------
  41.  
  42. Since FP and Int data are essentially different classes of information and
  43. use different parts of the CPU - (Just like instructions and data) - should
  44. we provide two caches and two paths to cache?  Would this double memory
  45. throughput in FP intensive code?
  46.  
  47. We modified Mike Johnson's superscalar processor simulator to support two
  48. data caches - one for ints and one for FP.  We also increased the internal
  49. L/S units and the L/S busses to support the extra BW required.  If FP and
  50. integer data exist of the same cache line - a snooping mechanism would
  51. maintain coherency.  
  52.  
  53. We found that the speedup was no more than 2-3% higher than using a single
  54. cache of combined size.  In non-FP codes, the larger single cache was better.
  55.  
  56.  
  57. Explanation:
  58. -----------
  59.  
  60. We believe that the explanation is that during FP intensive operations, most
  61. programs use only a few addressing integers and keep these in registers.
  62. Therefore, while FP and Integer BW are both important - they are not usually
  63. used at the same time.  Some programs with pointer-based data stuctures may
  64. respond differently. (We used SPEC programs).
  65.  
  66. I still have hope for multiple caches - but not using FP/Int classifications.
  67.  
  68.  
  69. Want more info - Princeton Univ Tech. Rept. CE-A92-2 can be requested from
  70. me.
  71.  
  72.  
  73. (Philosophical note.  This experiment also raised the issue of whether or
  74. not the architecture community will accept the publication of negative
  75. results.  We could not locate any recent papers in major conferences that
  76. did not have positive results)
  77.  
  78. -- 
  79. --------------------------------------
  80. Andrew Wolfe
  81. Assistant Professor
  82. Department of Electrical Engineering
  83. Princeton University
  84.