Westmere 12 core 2.66 memory configuration

The best places to buy ram for Apple are OtherWorldComputing and TransIntl.

They do extensive tests to their memory and OWC Memory is Backed by a 30 Day
Money-Back Guarantee and a Lifetime Advance Replacement. Warranty/Guarantee.

I used OWC memory for years in several different Macs without a single problem.

OWC states that their 8GB modules can not be mixed with modules of different
sizes. TransIntl does not state any restrictions.

3x8GB kits are $1088 and $894 from OWC and TransIntl respectively.

If mixing of 8GB and 2GB is allowed, it is better to have 3 of each size so
all your ram will be accessed in triple channel.

 

Having 3 8GB sticks doesn't give you triple-channel performance unless you put them all on the same side (i.e. in slots 1-2-3 or 5-6-7).

What it's easy to forget with an 8 or 12-core Mac Pro is the Nehalem/Wetmere's so-called "NUMA" or Non-Uniform Memory Architecture. Without going into a lot of mumbo jumbo, each of the machine's two CPU's has only four local memory sockets that it can address at maximum performance (i.e. triple channel if you put 3 sticks of the same size in the front 3 sockets).

The four sockets on the other side, that is, the other CPU's local memory, are a different story. Both CPU's can of course access all the memory in the machine, but not with the same level of performance...that's why they call it "non-uniform".

If a core on CPU 1 needs data from a memory module local to CPU 2, it can't get that data at the same speed as its own local sockets, because its memory hardware can't address those "remote" sockets directly. Instead, it has to first send CPU 2 a message over the interprocessor QuickPath link, and then CPU 2 gets the data from its local memory and passes it back to CPU 1 over the same QuickPath link. In other words, there's extra latency if one CPU has to access another CPU's local memory.

The operating system is supposed to try to minimize that, i.e. to keep a program and its data together on one CPU and its local memory. It's not always possible on a busy machine, but it usually is possible, so NUMA is yet another issue that sounds scarier in theory than it is in practice.

But the thing that should be kept in mind is the locality of memory sockets.

If you're mixing module sizes, then simply having 3 8Gb modules in the computer does not at all guarantee you triple-channel memory performance unless you put them all on the same side. On the contrary, if you get three, and you put two on one side and only one on the other, what you're actually doing is guaranteeing a slowdown in LOCAL access from double to single-channel for the solitary 8GB stick. Note this is not strictly a NUMA issue because it's the same effect as putting one 8GB stick and two 2GB sticks into a single-CPU quad or hex MP. The solitary 8GB stick will get single-channel access speed.

So the configurations that the Crucial guy gave you seem weird to me. Three sticks good, yes. Splitting them up with two on one side and one on the other, bad. If you're going to split them and use different sizes, you should get four 8GB sticks, not three. That way, all your memory will get two-channel access (none will get single- or triple- channel).

Better yet, just forget your troubles and get six 8GB sticks and donate the 2GB sticks to the needy.

 

Yes, that will work and give you 3-channel performance on one of your CPU's (the one with the 3 8's) and dual channel on the one with the 4 2's. (it's a long story discussed on other threads...once you fill the fourth socket, the memory performance is limited to dual-channel even if the sticks are all the same).

The problem is that the imbalance (24GB local to one CPU and only 8GB local to the other) will to some extent tie the OS's hands if your machine ever gets very busy. I assume that the reason people buy double-CPU machines is that they frequently need a lot of cores and threads and programs running at once...after all, if they don't, then why not just stick with a single CPU?

However that means that you want ample memory local to both CPU's when that high activity level happens. But because of the 24/8 memory imbalance you're thinking about, the OS may have to start executing threads on a CPU which has some or all of their data on the other side, in which case you take an inter-processor performance hit.

This is all nebulous and very dependent on exactly how you use your computer. But personally, I would opt for balancing the memory sizes in the two four-socket sets. I really would consider getting that fourth 8GB stick and going 8-8-2-2 on both sides. You'll get dual-channel instead of triple-channel memory performance. But you're much less likely to get the operating system scratching its head about what to put where if and when your system gets very busy.

I obviously have no numbers to back this up but I don't believe you'll notice a difference between dual- and triple-channel memory performance in real-world situations. I'd rather have dual-channel memory performance all the time than a frequent risk of cross-CPU memory access.

Once again, it's impossible to know how much the effect of either layout will be without actually measuring your real-world workload. But I myself would definitely go for balanced memory size on each CPU.

 

Your optimal configuration for maximum performance will be 24GB (6 x 4GB chips) configured as 3 chips in each of the two processor's slots, with the slot closest to the processor being left empty. This allows for full DDR3 triple channel memory acceleration, and you will get the most performance out of this configuration. Your system will be slower with 16GB (8x2GB) or 32GB (8x4GB) installed. Even with 64GB, you system would be slower than with 24GB. 24GB is the optimal configuration for the dual processor 2009/2010 Mac Pro. I have a Single Quad 2009 Nehalem model, and I just removed one of my 4GB chips, giving me 12GB total, and my Geekbench score improved 112 points, with improvements in processor and floating point scores. My whole machine feels a ton faster now, no lag at all.