home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / hardware / 16991 < prev    next >
Encoding:
Text File  |  1992-09-14  |  3.6 KB  |  99 lines
  1. Newsgroups: comp.sys.mac.hardware
  2. Path: sparky!uunet!nwnexus!kanefsky
  3. From: kanefsky@halcyon.com (Steve Kanefsky)
  4. Subject: Re: Daystar Powercache (need info...)
  5. Message-ID: <1992Sep14.152454.21271@nwnexus.WA.COM>
  6. Sender: sso@nwnexus.WA.COM (System Security Officer)
  7. Organization: The 23:00 News and Mail Service
  8. References: <1901vqINNkah@burr.cs.utexas.edu> <1992Sep13.214046.7300@nwnexus.WA.COM> <1913mpINNfvb@mohawk.cs.utexas.edu>
  9. Date: Mon, 14 Sep 1992 15:24:54 GMT
  10. Lines: 87
  11.  
  12. In article <1913mpINNfvb@mohawk.cs.utexas.edu> newton@cs.utexas.edu (Peter Newton) writes:
  13. >> I expect that the 33mhz '040 PowerCache due out soon will beat the
  14. >> Quadra 700 and 900 on the Math and CPU related stuff, and be very
  15. >> close to (possibly even ahead of) the Quadra 950 in these areas.  The
  16. >> 16-bit data path of the LC II has very little effect once you go to an
  17. >> external cache. 
  18. >
  19. >I wonder.  Just how much cache memory comes with with Daystar
  20. >PowerCaches?  One problem with with small benchmarks like those built
  21. >into speedometer is that they tend to fit entirely within even fairly
  22. >modest caches.  Things might be a bit different with production sized
  23. >apps, depending on their locality.  It would be interesting to do some
  24. >timings with larger programs.
  25.  
  26. Ah, a perfect opportunity to present my "real-world" benchmarks.  Last
  27. night I decided to remove the PowerCache and do some benchmarks, after
  28. which I put it back in and ran the same benchmarks.  I tried to be as
  29. careful as I could about not letting caches (either disk or RAM) confuse
  30. the test results.  I always tried to flush the caches before running each
  31. test (e.g. before running an Excel test, I would open up Word).
  32.  
  33. The results seemed to agree with the Speedometer benchmarks pretty well.
  34. Naturally, if Speedometer says that the CPU is three times faster and the
  35. disk is only 20% faster, than a task involving both disk and CPU will be
  36. somewhere between 20% and three times faster.
  37.  
  38. (BTW, the answer to your question about the cache is that it's 32K
  39. direct-mapped)
  40.  
  41. So, without further ado, here are the benchmarks I ran and the results:
  42.  
  43.  
  44. Boot time from Restart (with just the          32 sec               28 sec*
  45. Daystar PowerStation control panel)
  46.  
  47.  
  48. Boot time from Restart (with a dozen           52                   40*
  49. or so extensions)
  50.  
  51.  
  52. Time to launch MS Word 5.0                     24                   12
  53.  
  54.  
  55. Time to launch MS Excel 4.0                    29                   16
  56.  
  57.  
  58. Time to launch MS Excel 4.0 (with several     117                   50
  59. linked worksheets and add-ins, including
  60. the time to finish re-calc)
  61.  
  62.  
  63. Time to uncompress and display GIF file        32                   12
  64. in Giffer 1.2 (503K after decompression)
  65.  
  66.  
  67. Time to de-binhex 303K .hqx file in DeHQX      43                   22**
  68. (216K after de-binhex-ing)
  69.  
  70.  
  71. Time to compile Art Class demo in THINK C     1045                 386
  72. 5.0 from scratch
  73.  
  74.  
  75. ----------
  76.  
  77. * Note that the PowerCache boots with it's 32K cache off, eliminating a
  78. lot of the advantage until the PowerCentral control panel loads and turns
  79. on the cache.  Loading PowerCentral first speeds up the rest of the boot
  80. process.
  81.  
  82.  
  83. ** It was very clear in the DeHQX test that disk access took most of the
  84. time.  The program would just fly through a chunk of the decoding process,
  85. then sit there and wait while it wrote out to disk, then continue with the
  86. next chunk.  I didn't get a chance to test this with a RAM disk, but I
  87. suspect the difference would have been much greater.
  88.  
  89. I may do another round of benchmarks, so if anyone has any specific
  90. suggestions on what to test (you can send me sample documents if you
  91. wish), I'd be happy to try them out.
  92.  
  93.  
  94.  
  95. Thanks,
  96. --
  97. Steve Kanefsky
  98.  
  99.