Thinking of a new MacBook Pro L2 Cache matter for Fusion?

[nyc2socal]

I did a quick search and didn't see anything. I'm planning to buy a new MacBook Pro, and was trying to decide between the 2.4Ghz 3MB L2 Cache and the 2.5Ghz 6MB L2 Cache. The most intensive task I run is on Fusion (running test servers, etc). Does 6MB Cache make a difference to Fusion?

[nyc2socal]

So I guess getting an additional 3MB of cache won't show any difference in Fusion. Either that, or no one has compared/tested the differences.

[Pat_Lee]

There are no definitive benchmarks to share, but more memory and more cache is always a better thing when running in a virtual machine.

Pat

[nyc2socal]

Thanks Pat! The MBP will have 4GB of RAM, just pondering on the cache.. thanks!

[matthewls · Accepted solution]

Memory and cache help every program run faster, and the larger the memory footprint of the running programs, the more they help. The new huge caches of the core 2 duo chips are an important reason that they beat up on the AMD chips. If you can keep your entire working code on the CPU, it's going to fly faster than if the same code has to be swapped between RAM and CPU. Acceessing L2 caches can be 2-10x faster than RAM, and don't require the memory transfer overhead. According some descriptions I've read, the huge Intel caches ramp up performance despite their slow RAM access relative to AMD chips. In tests described on wikipedia, increasing the L2 cache from 2-4 MB on core 2 duos improve performance up to 16%

[nyc2socal]

Thanks for the verbose response!! I did not realize the CPU cache was so much faster than RAM.. but the memory transfer overhead does make sense. Thanks!

[admin]

There's orders of magnitude speed (and cost-per-byte) difference between each level of caching (L1, L2, L3 if present, RAM, disk) - it's the same reason that virtual memory (which uses disk) is no replacement for actual RAM. How much of a difference an increased cache size makes depends on the workload - if it fits in the cache, you'll see an enormous improvement, but if you're doing random reads across a huge dataset, it won't help.

My wild guess is that the increased cache will help, but I have no data to back this up.

[nyc2socal]

So that makes sense. In essense, the order of speed is CPU Memory (Cache), then RAM, then Virtual Memory (HDD). Which kinda wraps back towards my original thoughts.. Mac OS X being based on BSD probably has some robust memory management features. With that in consideration, I would assume that the L2 Cache would utilize frequently referenced data and or processes. Now not really knowing the underlying wiring and configuration of Fusion, I do not know how or if Fusion is tailored to utilize the CPU cache effectively/efficiently/at all.

At this point, I think the biggest advantage by having more L2 Cache would probably be host level applications running, and the Fusion running the guest vitrtualized machine as secondary.

[pisymbol]

Just to note, Virtual Memory (VM) has nothing to do with hard disk nor speed. In fact VM slows down a direct mapped address space since you have a separate Memory Management Unit (MMU) that performs translation (and thank god its in hardware or things would really be slow). In fact Intel has a two-stage translation for every physical address (segmentation and virtual memory).

VM's main purpose is to present a coherent address space despite the actual physical memory installed, i.e. RAM. Without VM, when a process runs out of memory addresses, it would have to be entirely swapped out for another process (swap space is what I think people are referring too, when pages are written to hard disk which is very rare these days with *NIX based OSes and amount of RAM systems ship with). Moreover, VM also gives you a way to segment address spaces for code, data, and stack which helps prevent memory corruption across processes.

In terms of virtualization, its even tougher since classical techniques include shadowing the page tables, trapping on access, determining if its a real page table update by the Host OS or an update of the guest, updating the shadow tables, etc. Trust me, VM slows things down quite a bit and I'm sure we may even see special virtualized VM units to solve some of these problems (for example Intel's VT helps with context switches between the hypervisor and guest but doesn't really solve the VM problems inherit in virtualization nor relieves some of the other issues inherit with the x86 architecture).

Back to your question about L2 cache size being bigger. It can't hurt but it may not make a difference. The guiding principle with memory is the more the merrier (bigger means less chance of a cache miss but really large caches can suffer from fragmentation and cache lookup latency as well)!! I have a MBP with 4GB of RAM and I have no issues at all running Fusion.

[Technogeezer]

To the hardware, Fusion (and the processes that run "within" it - they directly run on Intel CPUs) is another application and it will use those L2 caches like other applications, so I don't make the differentiation between MacOS processes and Fusion processes.

I don't think that MacOS's memory management really makes any difference here. In a system with sufficient physical memory, I would not expect memory allocated to the VM to be paged out by OS X. If for some reason parts of the Guest OS's memory allocation gets paged out, the no amount of L2 cache will help your performance or stability. (Hence the saying: Nothing helps virtual like real).

Running applications under Fusion now means that a guest OS's application's use of the L2 cache is not only competing with other applications in the Guest OS, but with the Guest OS code and applications in the host (Mac OS) as well. In a way, it's similar to running more processes within the host OS.

So, all other things being equal, the more L2 cache, the better the chances of avoiding a cache miss (and going to RAM) and hence the more potential for better performance. Of course, your performance gain will vary based on locality of reference of the code and data of the applications (how "cache friendly" they are) and the demands being placed on that cache by applications running on the system.