home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / misc / 16139 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  5.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!news-is-not-mail
  2. From: newton@cs.utexas.edu (Peter Newton)
  3. Newsgroups: comp.sys.mac.misc
  4. Subject: Virtual memory defeats IIsi cache size performance trick (long)
  5. Date: 7 Sep 1992 21:33:45 -0500
  6. Organization: CS Dept, University of Texas at Austin
  7. Lines: 124
  8. Message-ID: <18h3e9INNauk@mohawk.cs.utexas.edu>
  9. NNTP-Posting-Host: mohawk.cs.utexas.edu
  10.  
  11. What follows is a long discussion of the "large cache" trick for
  12. speeding up the Mac IIsi.  The bottom line is that the trick appears
  13. to be defeated by virtual memory.  Details follow.
  14.  
  15. First some background for those who are not aware of this.  The Mac
  16. IIsi contains 1 MB of RAM that is soldered to the motherboard.  This
  17. RAM is dual-ported to the system bus and to the onboard video.  The
  18. result is that accesses to this memory by the CPU contend with those
  19. from the video.  Hence this memory is effectively extra slow.  A
  20. program executing in this memory can run at less than half speed in
  21. the worst case.  An approach to solve this problem has been to devote
  22. this memory to
  23.  
  24.    1.  Video ram
  25.    2.  Disk cache (even the slow memory is fast relative to a disk).
  26.  
  27. This way, the slow memory is entirely occupied so your programs can
  28. never run in it.  You do this by setting the disk cache to a "large"
  29. value.  See below for how large.
  30.  
  31. The dual-ported memory is physically at address 0.  This trick works
  32. because Apple uses the 68030's MMU to map it to the high end of a
  33. contiguous block of memory.
  34.  
  35. An aside.  Another solution to this problem is to run your IIsi set to
  36. use less than 256 colors.  Black and white is best.  This reduces the
  37. video's demands on the dual-ported RAM.  However, I *like* 256 colors
  38. so I always run at that setting.
  39.  
  40. Anyway, I became curious about two things.  First, how big must the
  41. disk cache be to use up all of the dual-ported RAM?  Second, does
  42. virtual memory screw up the page mapping and defeat the trick?
  43.  
  44. To explore, I wrote a quick and dirty little program that allocates
  45. all the RAM it can and times writes to various locations in memory to
  46. look for slow ones.  One expects it to find slow memory at the top of
  47. the address space, if the disk cache is too small, and this is what
  48. happens.  Writes to the dual-ported RAM take 2.9 times as long as
  49. writes to the regular RAM, assuming the video is set to display 256
  50. colors.
  51.  
  52. How big must the disk cache be?  Measurement suggests that the formula
  53. that John Bruner sent to me is at least close to correct.
  54.  
  55.   Set Disk Cache = 1 MB - VideoRam - SpaceUsedByInits
  56.  
  57. VideoRAM = 640*480 = 300 KB for 256 colors.  Inits allocate space in
  58. high (and so slow) memory.  If you use no inits, SpaceUsedByInits will
  59. be zero and you need a disk cache of at least 724 KB.  My inits
  60. allocate about 500 KB so I can set the disk cache to a much smaller
  61. value.  Some people on the net have said that 384 KB is enough.  That
  62. is not strictly correct.  It depends on your inits.  There is a lot
  63. of folklore in this.
  64.  
  65. The next question.  What happens when virtual memory is turned on?
  66. The answer is unpleasant.  The slow memory appears to no longer be
  67. mapped to the high end of the address space so the trick stops
  68. working.  Even with a a disk cache of 768 KB, I find slow memory
  69. sprinkled throughout the address space-- appearing wherever pages
  70. happen to be mapped.  This means that if you must use virtual memory,
  71. you may as well use normal disk cache sizes and live with the fact
  72. that performance will suffer (perhaps a lot) whenever something
  73. important happens to run in the dual-ported RAM.
  74.  
  75. This annoys me a bit since I cannot afford to buy big SIMMS right now
  76. and turn off virtual.  Maybe Apple (hint!) or someone who knows how
  77. will write an init that automatically allocates all of the dual-ported
  78. RAM not used by video to something where speed is not necessary-- like
  79. the disk cache, even when virtual is on.  I think I would buy big SIMMs
  80. before solving the problem by buying a video card.
  81.  
  82. There is much room for error in the kind of measurements I made so I
  83. am not going to be dogmatic and declare myself infallible.  Instead, I
  84. will attach the measurement part of the code I used.  Mem is a pointer
  85. to the address being timed.  I do not think that I was just seeing
  86. page faults because I measure each location twice.  The fault would
  87. affect only the first.  My system is a IIsi with 5 MB RAM, both Sys
  88. 6.0.8 and tuned 7.0.1 tried.  256 colors always.  8 MB of virtual RAM
  89. when enabled.  I have never turned 32 bit mode on.
  90.  
  91. If you compile this, turn off all optimization and ensure that Mem and
  92. j are in registers.  I dissassembled the code to ensure that I had
  93. Thick C 5.0.1 doing the right thing.  Anyone know how the 030's little
  94. data cache works?  It appears to affect reads but not writes in this
  95. context.
  96.  
  97.      Start1 = clock();
  98.       for (j = 0; j < 50000; j++) {
  99.          *Mem = j;
  100.          *Mem = j;
  101.          *Mem = j;
  102.          *Mem = j;
  103.          *Mem = j;
  104.          *Mem = j;
  105.          *Mem = j;
  106.          *Mem = j;
  107.          *Mem = j;
  108.          *Mem = j;
  109.          *Mem = j;
  110.          *Mem = j;
  111.          *Mem = j;
  112.          *Mem = j;
  113.       }
  114.       Start2 = clock();
  115.       for (j = 0; j < 50000; j++) {
  116.          *Mem = j;
  117.          *Mem = j;
  118.          *Mem = j;
  119.          *Mem = j;
  120.          *Mem = j;
  121.          *Mem = j;
  122.          *Mem = j;
  123.          *Mem = j;
  124.          *Mem = j;
  125.          *Mem = j;
  126.          *Mem = j;
  127.          *Mem = j;
  128.          *Mem = j;
  129.          *Mem = j;
  130.       }
  131.       printf("%ld %ld %ld\n", Mem - Base, Start2 - Start1, clock() - Start2);
  132. -- 
  133.  ----
  134. Peter Newton (newton@cs.utexas.edu)
  135.