home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sgi / 11491 < prev    next >
Encoding:
Text File  |  1992-07-27  |  1.3 KB  |  31 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!wsu-cs!hal!atems
  3. From: atems@hal.physics.wayne.edu (Dale Atems)
  4. Subject: Memory interface and performance of R4K Indigo
  5. Message-ID: <1992Jul28.021405.27412@cs.wayne.edu>
  6. Followup-To: Re: Memory interface in R4000 Indigo
  7. Originator: atems@hal
  8. Sender: usenet@cs.wayne.edu (Usenet News)
  9. Organization: Dept. of Physics, Wayne State University
  10. Date: Tue, 28 Jul 1992 02:14:05 GMT
  11. Lines: 18
  12.  
  13. Thanks to all who responded to my question about the CPU-main memory interface
  14. on the R4000 Indigo. All are agreed that the penalty for a secondary cache miss
  15. is about 100 CPU cycles. This brings up two questions:
  16.  
  17. 1). Why 100 cycles? If the CPU is clocked at 50 MHz, a single clock cycle takes
  18. 20 ns. If main memory consists of 80 ns DRAM, I would expect a penalty on the
  19. order of 4-5 CPU cycles, not 100. (I assume my understanding of these issues
  20. is flawed somewhere. Please correct me here, I do not claim any expertise.)
  21.  
  22. 2). Standard CPU/FPU benchmarks should fit easily into a 1MB cache, so I don't
  23. expect to see the effects of cache misses reflected there. Has SGI/Mips done
  24. any internal studies on how significant this effect will be on the performance
  25. of "real" code?
  26.  
  27. Thanks for any insights/information,
  28.  
  29. Dale Atems
  30. E-Mail: atems@hal.physics.wayne.edu
  31.