Mac Pro memory performance (Stream)

[hehejames]

Yes, I get 8 gigabit or 1 gigabyte speeds!

http://www.haxial.com/download/Benchmark1000-Mac.sit

Geekbench? I wouldn't take anything it said seriously.

Thanks Tesselator. Looks like I'll have to run Haxial as well to make me feel a bit better. Regarding Geekbench; you already made me feel better.

I just don't like the fact that a vendor selling RAM has a dedicated web-page called "Mac Pro Memory" and sharing test results using a custom tool that is not available to the general public. Who knows even if that tool exists or works...

On a separate note... OWC maintaining/continuing to host such web-pages (Mac Pro Memory test & results) on their own site could be seen as a conflict of interest. Also, extremely unethical business practice.

Why? Hosting such data possibly leads customers to buy more memory than needed. Don't want such perception? just remove that entire page? or host a different set of data where customers can replicate those performance benchmark.

What good are those charts if OWC's customers can't even replicate the test results? No one drives on the freeway/highway on their newly picked up vehicle at 150MPH, but when manufacturer claims it can be done people want to try. When they try and can't get there... then people start to complain and open the flood gate to forums/social networking/blogs/etc.

 

[hehejames]

Yikes! Isn't this memory performance a key justifier to upgrade to a Nehalem-based Mac Pro?

Nehalem's tri-channel 1066 DDR3 is three times faster and I'm assuming FB-DIMM latency is an added killer.

Perhaps... But this post was specifically written/to discuss how to replicate OWC's test results/claims and why they are using custom bechmark/test case/results that can't even be replicated by consumers to reference when purchasing RAM. I don't mind the reports residing on Bare Feats, but do have a problem when its directly hosted on a vendor's page. It's just unethical and such information can only be perceived as a tool to sell more RAM packaged at specific quantities/etc.

Also, you do bring up a good point. As you have mentioned, the 1066 DDR3 is faster compared to the 800Mhz. If the so so so special "64 bit parallel multi-threaded version of the STREAM benchmark test" is accurate and good enough to be used/referenced by a vendor selling RAM, why wasn't the same test applied to the 09 Nehalem and share those as well?

 

[hehejames]

Fair enough. Despite having links to the test for more information on the test itself, we have added the same wording to our test site to help eliminate any possibility of misunderstanding.

Thank you for making changes on your site.

But... If you are so confident on the test result generated from "custom/special 64-bit parallel multi-threaded version of the STREAM benchmark test" Why aren't you using the same tool to test the Nehalem's and share the results for those as well?

As a vendor, you should implement a common methodology on how/why things are tested certain and why/how your reports are generated.

 

[hehejames]

Glad to see OWC can admit they were wrong. Thanks for clearing that up for everyone who might be misled.

Yes... There aren't many companies/vendors like that, but the record must be set straight.

 

[VirtualRain]

Perhaps... But this post was specifically written/to discuss how to replicate OWC's test results/claims and why they are using custom bechmark/test case/results that can't even be replicated by consumers to reference when purchasing RAM. I don't mind the reports residing on Bare Feats, but do have a problem when its directly hosted on a vendor's page. It's just unethical and such information can only be perceived as a tool to sell more RAM packaged at specific quantities/etc.

Also, you do bring up a good point. As you have mentioned, the 1066 DDR3 is faster compared to the 800Mhz. If the so so so special "64 bit parallel multi-threaded version of the STREAM benchmark test" is accurate and good enough to be used/referenced by a vendor selling RAM, why wasn't the same test applied to the 09 Nehalem and share those as well?

I'm appologize for hijacking your thread... I was just shocked at the poor memory bandwidth being reported. Something is not right. It shouldn't take a 64-bit multi-threaded app to saturate the front side bus or memory bus!

It's important to note that with dual-channel DDR2 as used in Harpertown, it's theoretically the FSB speed that limits memory bandwidth. In Harpertown (and every generation of CPU Intel made between the 486 and Nehalem), the CPU(s) connect to the memory controller in the NorthBridge chipset via the Front Side Bus. This bus is clocked at a multiple of 66MHz and over the years increased with each generation of CPU/chipset until Harpertown which ran at a FSB of 333MHz. (Good question: do all Harpertown CPU's run at 333MHz FSB?!).

The implications of this are that the 64-bit wide FSB running at 333MHz capable of a transaction on each clock edge (quad-pumped) provides a maximum theoretical memory bandwidth of 10.6GB/s.

Dual channel DDR2-800 memory runs the memory modules at 200MHz and the data bus at 400 MHz, offering a maximum theoretical bandwidth of 12.8GB/s on a 128bit wide bus (400MHz x 2 channels x 16 bytes/channel). Thus the FSB is the limiting factor here and it's precisely for this reason that Intel had to move to an on-die memory controller with Nehalem to eliminate the FSB bottle-neck in memory performance.

Now you won't see theoretical maximums, but you should get somewhere around 80% with a proper benchmark.

What is going on here?! I think the benchmark is hosed. I still don't understand why you need a 64-bit multi-threaded app to saturate this memory architecture. That certainly wasn't necessary on Windows. SiSoft has been providing reliable memory bandwidth benchmarks under Windows for as long as I can remember.

 

[Tesselator]

--- Good info snipped ----- ✄ ---

What is going on here?! I think the benchmark is hosed. I still don't understand why you need a 64-bit multi-threaded app to saturate this memory architecture. That certainly wasn't necessary on Windows. SiSoft has been providing reliable memory bandwidth benchmarks under Windows for as long as I can remember.

Good question. But if it's the benchmarking apps then all 5 of them are hosed in the same way? <scratches head>

 

[VirtualRain]

Good question. But if it's the benchmarking apps then all 5 of them are hosed in the same way? <scratches head>

LOL... Here are my results... equally dismal given Nehalem's capability... I expect this benchmark is junk (although as you say Xbench reports similarly poor results).

We need someone to run Everest or Sisoft Sandra on Windows (anyone with a Windows drive or Bootcamp?)... to gain some sanity here.

EDIT: Added 64-bit benchmark results... better but a) it shouldn't make a difference and b) still out by about a factor of 3-4

 

[VirtualRain]

In drilling into this more, I think there's a lot more to FBDIMM robbing performance than I thought.

I've revisited Anand's review of the 2006 Mac Pro where they delved into FBDIMM memory performance in some detail...

It's not Apple's fault, but FB-DIMMs absolutely kill memory latency; even running in quad channel mode, the FB-DIMM equipped Mac Pro takes 45% more time to access memory than our DDR2 equipped test bed at the same memory frequency. Things don't get any prettier when we look at memory bandwidth either.

Remember the overhead we were worried about with the serialization of parallel memory requests? With four FBD channels, the best we're able to see out of the Mac Pro is 4.292GB/s, compared to the 6.782GB/s of bandwidth our dual channel Core 2 testbed is able to provide. The efficiency table below says it all:

<snip>

FB-DIMMs are simply not good for memory performance; the added capacity allowed by having 8 FB-DIMM slots on the Mac Pro had better be worth it, because if Apple were to release a Core 2 based Mac chances are that it could give the Mac Pro a run for its money in a number of memory sensitive tasks.

More info on FBDIMMs in the Mac Pro here: http://www.anandtech.com/mac/showdoc.aspx?i=2832

While this may raise more questions than it answers, (e.g. how did Barefeats and OWC get 75% efficiency from FBDIMMS when Anand can only get 40% - albeit from a previous gen architecture)... it may imply that I was way off base in suggesting you might see 80% of theoretical bandwidth from a 2008 Mac Pro.

I wish Anand would do a full review of the 2009, and I'm guessing you guys wish they had done a proper review of the 2008.

 

[Tesselator]

Yeah, that would have been nice. I won't speculate on BareFeats in specific but I know I don't believe a lot of what they post up there. Just the few times I've investigated stuff there were quite a few fudge-factors being employed either knowingly or unknowingly. I don't know almost anything about OWC.

Your benchmarks are what I would expect given the ones from my 2006 2.66 Octad w/8-FBDIMMs. I score about 2000 with 2.5 GB/s ~ 3.0 GB/s in the same test. So the 2009 is about 1.5x to 2.0x from the 2006. I expect that the 2008 would land in the middle somewhere.


.

 

[VirtualRain]

Not being satisfied with Geekbench, I finally got around to installing Win 7 on my Mac Pro today and immediately set about running some benchmarks I trust.

I think we can safely conclude that Geekbench is a POS for memory benchmarking.

Sandra shows the peak bandwidth at 18GB/s while Everest shows a more practical 14GB/s.

Another interesting fact is that when I changed my power profile in Windows from "Balanced" to "Performance" the CPU speed stayed in "Turbo Mode" as shown in the CPUz screenshot (3057MHz or 1 multi higher than spec).

Ok... back to OSX now (I feel dirty working in Windows! )

 

[nanofrog]

Ok... back to OSX now (I feel dirty working in Windows! )

Nah...the Kool-Aid wore off, and it's time for a new dose.

 

[Tesselator]

Geekbench is a POS

Well, it's certainly a better explanation than concluding a MB Mb mixup.

It's a vindication for what I've been saying about Geekbench and XBench at the same time too.