Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is Tri Channel functionality maintained when 4th memory stick used?
- Thread starter fruitatcost
- Start date
- Sort by reaction score
I'd gladly go from 6GB to 12GB, but the price (at OWC) on a quad goes from 118$ to 540$...For now I'll take the theoretical memory speed hit with 8GB, and prevent more VM usage...
Also, OWC results are interesting... Unless I'm misreading them, they actually show that for 2 apps, the theoretical "hit" in RAM speed by going from 6GB to 8GB on a quad, and 3*4GB to 4*4GB on an octo, is inexistent in real applications. And in After Effects, that 12 -> jump actually increases performance...
Loa
Agreed... the practical impacts are negligable in most applications. The huge cache on modern processors really reduces the impact memory bandwidth plays in real-world application performance. Few apps really stress the memory sub-system to the point that it becomes a bottle-neck... hence the prior recommendation that having enough memory is more important than the speed of it.
Thx! Although I'm afraid I can't fully understand the page ins and outs, and what they actually mean...
Hmm, I wonder if this theoretical Vs real-world is also applicable to SSDs Vs RAID0s... haha, just kidding!
Loa
"Unless a user's X system is performing swapping there's absolutely no need to worry about the swap file size nor its location. Swapping activity is provided by observing the "0(0) pageouts" in the last header line of the Terminal top command. Another useful Terminal command is the vm_stat(1) command (see man vm_stat). This command also displays the number of Pageouts. The pageout value is an indication that physical memory is being paged(swapped) to the swap file. This i/o is done in page chunks. A page chunk is 4096 bytes in size.
When physical memory is paged (swapped) to the swap file it is being done so because physical memory is being over-subscribed. The best solution for avoiding frequent over-subscription of physical memory is to have fewer Apps running at same time or install more physical memory. When physical memory becomes over-subscribed the OS will seek out inactive memory pages and copy them to the swap file in order to make room for the active memory pages -- which may have to be copied from the swap file back into physical memory. "
http://www.macosxhints.com/article.php?story=20010613140025184
Hehehe, you little trouble-maker you.
Hello Tess,
Ok, now I have a better idea of what the terms mean.
But this method of simply "adding up" all the pages seem quite brutish... Are there other apps that will tell you what happened in more detail? A sort of paging history since your last restart?
Thanks
Loa
Ok, now I have a better idea of what the terms mean.
But this method of simply "adding up" all the pages seem quite brutish... Are there other apps that will tell you what happened in more detail? A sort of paging history since your last restart?
Thanks
Loa
Yeah, the MenuMeters just tells you how many pages it's dealing with at any given moment. It's not an accumulated tally tho. As for histogramming the results or graphing page activity I guess could be useful - especially if you could see the associated application. Instruments.app in the XCode dev tools does this. It's free.
Yeah, the MenuMeters just tells you how many pages it's dealing with at any given moment. It's not an accumulated tally tho. As for histogramming the results or graphing page activity I guess could be useful - especially if you could see the associated application. Instruments.app in the XCode dev tools does this. It's free.
Ok. Last question to make sure I understand correctly: if I had 500GB of RAM, I would always have 0/0 pages, right?
Loa
No. You'd still have them. Just the way OS X works. I get 50K pageins just starting
up the machine. By the time I've opened a few folders and an application I'm at
100,000. Pageouts will still happen too but not as much in most cases. 32bit apps
will set them off many times if you're working with large files or many files. I'm
not sure on the theory exactly but I assume if you were using all 64-bit apps and
you only used one or two apps at a time then you might not ever see any pageouts
unless your document data was 495 GB or something. I almost never see any with
12GB RAM. I do when 32bit apps are working on MASSIVE files occasionally.
EDIT:
After a fresh restart, browsing a few 500 image folders, loading Photoshop
(a 32-bit app) and opening/creating a 30 layer 32-bit 24MP image (to try
and get some page-outs), and then quitting PS again, my stats look like this:
This stats display box is showing counters for pageouts and pageins (accumulative)
After a fresh restart, browsing a few 500 image folders, loading Photoshop
(a 32-bit app) and opening/creating a 30 layer 32-bit 24MP image (to try
and get some page-outs), and then quitting PS again, my stats look like this:
Ok. So how do I know if I need more RAM? Using PS for example: can I check for that form within the app?
Thanks
Loa
Yeah, PS will tell you RAM and cache use. But typically you'll know you need more RAM when you see lots of page-outs. Or also if you notice Memorymeters (or other memory monitor) graphing your used (active and wired), RAM up around your physical limits (whatever you have installed, 8GB, 12GB, whatever).
Here's a great article/review by Anandtech of the impact of RAM bandwidth on real-world application performance...
http://www.anandtech.com/memory/showdoc.aspx?i=3589&p=1
Further evidence that having enough memory is more important than faster memory.
It's interesting that with Nehalem, even with it's smaller cache sizes, it seems the bottleneck shifts to the CPU now (perhaps for the first time ever?!)... unlike Harpertown and previous generations where the FSB or the memory itself was often the bottleneck but compensated for with enormous cache.
http://www.anandtech.com/memory/showdoc.aspx?i=3589&p=1
Further evidence that having enough memory is more important than faster memory.
It's interesting that with Nehalem, even with it's smaller cache sizes, it seems the bottleneck shifts to the CPU now (perhaps for the first time ever?!)... unlike Harpertown and previous generations where the FSB or the memory itself was often the bottleneck but compensated for with enormous cache.
I'd like to apologise for posting some incorrect informtion here, due to Intel being super complicated of course
VirtualRain was right in that with 4 DIMMs it does interleave across 1&2 then 3&4, however you get better performance than straight dual channel. The loss is around 22-24% rather than 33%. However as the Mac Pros are using Unbuffered DIMMs there is another performance hit that you do not see with Registered DIMMs. When you put more than 1 DIMM on any channel basically the commands that take one clock cycle now take two with unbuffered DIMMs. Reducing by another 9%.
I was going on using 5 DIMMs over 6 slots which I knew did give you triple channel on the first bank of memory and then double channel performance on the second.
It doesn't really change much for the reality of memory purchasing though, capacity if you need it, 6 DIMMs if you want highest performance.
Also for those who want to use a mix of capacity sizes, you lose another 5-10% in bandwidth performance.
I hope this clears up some things.
VirtualRain was right in that with 4 DIMMs it does interleave across 1&2 then 3&4, however you get better performance than straight dual channel. The loss is around 22-24% rather than 33%. However as the Mac Pros are using Unbuffered DIMMs there is another performance hit that you do not see with Registered DIMMs. When you put more than 1 DIMM on any channel basically the commands that take one clock cycle now take two with unbuffered DIMMs. Reducing by another 9%.
I was going on using 5 DIMMs over 6 slots which I knew did give you triple channel on the first bank of memory and then double channel performance on the second.
It doesn't really change much for the reality of memory purchasing though, capacity if you need it, 6 DIMMs if you want highest performance.
Also for those who want to use a mix of capacity sizes, you lose another 5-10% in bandwidth performance.
I hope this clears up some things.
I'd like to apologise for posting some incorrect informtion here, due to Intel being super complicated of course
VirtualRain was right in that with 4 DIMMs it does interleave across 1&2 then 3&4, however you get better performance than straight dual channel. The loss is around 22-24% rather than 33%. However as the Mac Pros are using Unbuffered DIMMs there is another performance hit that you do not see with Registered DIMMs. When you put more than 1 DIMM on any channel basically the commands that take one clock cycle now take two with unbuffered DIMMs. Reducing by another 9%.
I was going on using 5 DIMMs over 6 slots which I knew did give you triple channel on the first bank of memory and then double channel performance on the second.
It doesn't really change much for the reality of memory purchasing though, capacity if you need it, 6 DIMMs if you want highest performance.
Also for those who want to use a mix of capacity sizes, you lose another 5-10% in bandwidth performance.
I hope this clears up some things.
This memory business is somewhat complicated and Intel don't give full information. But my understanding was that unbuffered memory was slightly faster than registered memory which takes one clock cycle to do buffering. Having a second DIMM on a memory channel reduces the maximum speed to 1066 from 1333 but since Apple set it at 1066 anyway I would have thought it would just stay at that. But I'm no expert and it is very hard to get any straight information especially on the 3500 series (the data sheets don't mention it whilst they do for the 5500 series). Dual channel and interleaving add to the fun.
I still don't understand why Apple don't allow registered memory. I'm puzzled by the OWC 4GB modules as they state that they don't work with the other modules which made me think that perhaps they are registered RAM but OWC specifically state that they are unregistered - perhaps they are some sort of hybrid?
This is correct.
This is also correct.
The unbuffered DIMMs just have an extra ovehead introduced when there are 2 DIMMs on a channel, making them slower than Registered. I had no idea about this, and have read most of the documentation. The person who told me about it described it as some sort of syncing that isn't needed with just one DIMM per channel. It explains where the extra performance drop comes from to bring the interleaving speed down to that of dual channel.
I don't know why they won't allow 1333MHz DIMMs to workon the 2.66GHz and 2.93GHz 8 cores either. They have crippled the Mac Pros when compared to workstations from other vendors.
I think this is just another incombatability issue.