folta@tove.umd.edu (Wayne Folta) (02/14/90)
We just installed 4Mb of memory in Bank B of our IIci, resulting in an 8Mb machine. The problem is that I was convinced by the Mac magazines that adding memory in Bank B would decrease video RAM contention and thus speed the IIci up. I have found no such speed increase. A (very) simple test: a recursive factorial function in LISP, yields the same run times with 1-bit and 8-bit color as when we only had 4Mb. So what's up? Was the Bank B magic a lie? Is my test too simple? Was the speedup only for graphics-intensive programs? -- Wayne Folta (folta@cs.umd.edu 128.8.128.8)
rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) (02/14/90)
In article <22499@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes: >We just installed 4Mb of memory in Bank B of our IIci, resulting in an 8Mb >machine. The problem is that I was convinced by the Mac magazines that >adding memory in Bank B would decrease video RAM contention and thus speed >the IIci up. I have found no such speed increase. [edited] >So what's up? Was the Bank B magic a lie? Is my test too simple? Was >the speedup only for graphics-intensive programs? No, the bank B magic is not a lie, no your test is not really to simple, and no, it's not just for graphics. The Mac IIci uses bank A as video memory. Reading of the memory by the video circuitry prevents the 68030 from getting unrestricted access to that memory. This is why the Mac runs slower when you switch to 8-bit video; more memory accesses go to video. Bank B memory doesn't have this problem. Video never reads from bank B and so the '030 can have unimpeded access to the memory. By running your programs IN bank B memory, your avoid contention with the video. The processor runs from bank B and the video from bank A. However, the Mac still loads programs into RAM from the bottom upward. Thus, on an 8 meg machine, your program is probably still running in the lower 4 meg (i.e., bank A). If you can get it to run in bank B, then you should see a speedup. This is also why 5meg is such an attractive configuration for the IIci. 1meg in bank A is usually used up by the video and system leaving only the 4 meg in bank B for running programs. Ray Fischer rcfische@polyslo.calpoly.edu
folta@tove.umd.edu (Wayne Folta) (02/14/90)
>By running your programs IN bank B memory, your avoid contention with >the video. The processor runs from bank B and the video from bank A. >However, the Mac still loads programs into RAM from the bottom upward. >Thus, on an 8 meg machine, your program is probably still running in >the lower 4 meg (i.e., bank A). If you can get it to run in bank B, >then you should see a speedup. This is also why 5meg is such an >attractive configuration for the IIci. 1meg in bank A is usually >used up by the video and system leaving only the 4 meg in bank B for >running programs. I forgot to mention that I was running under MultiFinder in System 6.0.4. I have heard it claimed that MultiFinder will automatically run stuff as high in memory as possible, so I assumed that I was in Bank B. I also shrunk LISP's memory down to 1500Kb before I ran it, guaranteeing it didn't wrap around into Bank A. Maybe an INIT is causing problems? I'll have to investigate further... -- Wayne Folta (folta@cs.umd.edu 128.8.128.8)
GFX@psuvm.psu.edu (02/14/90)
Here's the theory: In article <22513@mimsy.umd.edu>, folta@tove.umd.edu (Wayne Folta) says: > >In article <25d88b45.2cea@polyslo.CalPoly.EDU>, rcfische@polyslo.CalPoly.EDU >(Raymond C. Fischer) says: > >>By running your programs IN bank B memory, your avoid contention with >>the video. The processor runs from bank B and the video from bank A. >>However, the Mac still loads programs into RAM from the bottom upward. >>Thus, on an 8 meg machine, your program is probably still running in >>the lower 4 meg (i.e., bank A). If you can get it to run in bank B, >>then you should see a speedup. This is also why 5meg is such an >>attractive configuration for the IIci. 1meg in bank A is usually >>used up by the video and system leaving only the 4 meg in bank B for >>running programs. > >I forgot to mention that I was running under MultiFinder in System 6.0.4. >I have heard it claimed that MultiFinder will automatically run stuff as >high in memory as possible, so I assumed that I was in Bank B. I also >shrunk LISP's memory down to 1500Kb before I ran it, guaranteeing it >didn't wrap around into Bank A. > Here's some data: I ran MacSpeed (available from sumex-aim) to see what happens. I have a IIci / 8 Megs / Rodime 100i. I tried loading MacSpeed first ("low RAM") or above other applications totalling 6+Megs ("high RAM"). I have also tested the impact of the video setting: 1-bit BW and 8-bit color. The results are below. The numbers are standardized to the speed of a Mac SE. i.e. CPU of IIci, high RAM 8-bit video, runs 5.96 times faster than an SE. The results show minimal improvement wrt speed when you run 1-bit video. But if you have 8 Megs, applications in high RAM run as fast in "full" color as they would in BW. If you have 4 Megs or less, CPU slows down by 20%. INITs/CDEVs have a negligible impact on this benchmark. Would be interesting to see the results on a machine fitted with a video card. Stephane Set-up CPU Co-Processor Disk 1-bit / low RAM 5.8 12.16 3.25 8-bit / low RAM 4.72 9.84 3.10 1-bit / high RAM 5.97 12.39 3.24 8-bit / high RAM 5.96 12.39 3.23
folta@tove.umd.edu (Wayne Folta) (02/15/90)
I just did another test... I assumed that the wisdom that MultiFinder loads first into Bank B is incorrect. So, I loaded up programs until I had less than 4Mb left, then loaded LISP. This time, I got the 33% speed increase (27 clock ticks down to 19 clock ticks) in 8-bit mode that I wanted to see. So maybe MultiFinder isn't as bright as was previously assumed? -- Wayne Folta (folta@cs.umd.edu 128.8.128.8)
philip@Kermit.Stanford.EDU (Philip Machanick) (02/15/90)
In article <22540@mimsy.umd.edu>, folta@tove.umd.edu (Wayne Folta) writes: > I just did another test... I assumed that the wisdom that MultiFinder > loads first into Bank B is incorrect. So, I loaded up programs until > I had less than 4Mb left, then loaded LISP. This time, I got the 33% > speed increase (27 clock ticks down to 19 clock ticks) in 8-bit mode that > I wanted to see. > For your next benchmark: how about allocating a 3.5Mbyte RAM cache... Of course, all this leads to a potentially viable strategy: load your least speed-sensitive apps first, until Finder reports free space as less than 4M. Philip Machanick philip@pescadero.stanford.edu