Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Yeah, weird - this goes against what most everyone has said so far (sets of three will run at 25GB/sec and single/dual-channel for additional chips that run a bit slower.) Real world tests matter, but we'll have to see this corroborated by more examples.

But, if it's true, and 12GB of tri-channel RAM of the 2.26 starts kicking 16GB of RAM on a 3.2 for some applications...that will make things interesting...
 
wow very interesting.. so really the choice is either 6 or 12. I was going to go with 8 just for future upgradeability (so id have 2GB sticks) but i guess i should just start with 6 and then down the line when i'm ready for more i can sell the old ones back to OWC..
Kinda sucks though.. i really wanted to find a spot between 6 and 12 where i could still use 2GB sticks :/
 
wow very interesting.. so really the choice is either 6 or 12. I was going to go with 8 just for future upgradeability (so id have 2GB sticks) but i guess i should just start with 6 and then down the line when i'm ready for more i can sell the old ones back to OWC..
Kinda sucks though.. i really wanted to find a spot between 6 and 12 where i could still use 2GB sticks :/

Yeah, exactly my situation, plumped for the standard 6 and will now probably get 6x2 in a few months. Makes you wonder how fast it would be with 6x4, and all this on the 2.26. The 2.93 for the people who've got the cash is going to be a monster!

Going to be interesting to see if this also applies to other real world apps.
 
Your mileage may vary

The way that I interpret these results is "Your mileage may vary".

Benchmarks are only a guide, not some kind of wonderful absolute law handed down from on high.

Use the benchmarks as a relative comparison between machines, or when making changes to your machine.

I understand that using the 4th slot will force memory access to slow down somewhat. I will run some tests later today, once I get the ram.

Even if the memory access is somewhat slower, ram access is an order of magnitude faster the disk. So it will be interesting to see how this all relates to real life applications. :confused:
 
How did they test that? I thought the 2GB models have not been shipped yet..

edit: hmkay I got it :D
 
The way that I interpret these results is "Your mileage may vary".

Benchmarks are only a guide, not some kind of wonderful absolute law handed down from on high.

Use the benchmarks as a relative comparison between machines, or when making changes to your machine.

I understand that using the 4th slot will force memory access to slow down somewhat. I will run some tests later today, once I get the ram.

Even if the memory access is somewhat slower, ram access is an order of magnitude faster the disk. So it will be interesting to see how this all relates to real life applications. :confused:

Like I said, will be interesting to see if this applies to other real world apps. Look forward to seeing your results.
 
Wow looking at those benchmarks, I now believe that the 2.26GHz nehalem mac pro is WELL worth the buy and seems to be faster than even the 3.2GHz previous gen.

But its weird so this time around you shouldnt fill up all the last 2 slots if you choose to go with 2GB DIMMs to be faster than actually filling the last 2 spots with 2GB of RAM?? So its faster overall to just leave it at 12GB. Because if you choose to add 4GB DIMMS in the last 2 slots it still slows down as to the 12GB configuration... kind of strange.
 
Id still like to see the 2.26 with 8 gigs just to see what it looks like. With that config couldnt they put 2 sticks in each quad of DIMMs? Rather than filling up one side? There by not using up a 4th slot? I really have no clue if one of you know how it works that would be helpful. Id still rather get 2gig sticks that i could KEEP without having to remove entirely when i decide to upgrade..
 
So resuming, to get better performance with most applications on the 2,26. Get the 8GB(4*2GB) and then get another 4GB(2*2GB) aftermarket? Also, would it be better just to get the 6gb that come with the system and exchange for 6*2GB of the same type of memory?

-Thanks
 
I never fully understood how you could have triple channel and then a single channel that runs slower. I guess even if that is the case, you'll have to wait for whatever processes is running in the slower ram to finish before moving on to the next operation.

Usually RAM configurations default to the lowest denominator. I would of figured that it would just default to dual-channel since it's 4 slots of ram, while would theoretically be 33% slower. Although many hardware review sites have seen minimal impact of triple-channel versus dual-channel.

Ideally, Apple should have had 6 DIMM slots per CPU. Maybe in the next revision we will actually get a case redesign to accomodate a wee bit more space for more RAM.
 
Id still like to see the 2.26 with 8 gigs just to see what it looks like. With that config couldnt they put 2 sticks in each quad of DIMMs? Rather than filling up one side? There by not using up a 4th slot? I really have no clue if one of you know how it works that would be helpful. Id still rather get 2gig sticks that i could KEEP without having to remove entirely when i decide to upgrade..

You would need to equally split the RAM between processors as each processor will only see the RAM attached to it. SO for 8 Gig, sure, put 2x2GB next to each processor. However, it'll only run in dual-channel mode.
 
You would need to equally split the RAM between processors as each processor will only see the RAM attached to it. SO for 8 Gig, sure, put 2x2GB next to each processor. However, it'll only run in dual-channel mode.

I get that, i just wanna see what kinda hit that relates to in performance. If it doesnt end up being a big deal then maybe i just take a couple months dealing with dual-channel and then when i decide to upgrade ram later on to 3-channel i dont need to ditch any of the sticks currently in the system. I wish barefeats had included the 8gig spec in that bench
 
Memory benchmarks

Hi, y'all!

Just got my memory from OWC.

In a nutshell, my 2.26 octa results:

12 gb (6 * 2gb) max speed was 10,421 MB/sec.
16 gb (8 * 2gb) max speed was 9,024 MB/sec.

Seems that the timings for 12 gb were not that much different than 16 gb.

I am looking for my original benchmark (6 * 1gb), can't seem to find it now. If my memory is right, the 6 gb max speed was in the 8,000 range.

Here are the details:

====================
12 gb memory test
====================

dlt run-stress-test -d 5M -v OS

diglloydTools 1.1.0 64-bit Copyright 2006-2008 diglloyd, Inc. All Rights Reserved.
Thursday, March 12, 2009 12:47:50 PM PT
Physical memory (MB): 12288

********************************** Stress Test *********************************
System memory: 12GB
Test duration: 5m
CPU percent: 100% (per cpu core)
Num CPU threads: 16
Memory per thread (requested): 729.6MB

==> Determining amount of non-pageable memory
(this phase can take several minutes before stress-testing begins)


Checking for virtual memory paging for 11.4GB
No paging detected for 729.6MB (good)
No paging detected for 1.42GB (good)
No paging detected for 2.14GB (good)
No paging detected for 2.85GB (good)
No paging detected for 3.56GB (good)
No paging detected for 4.27GB (good)
No paging detected for 4.99GB (good)
No paging detected for 5.70GB (good)
No paging detected for 6.41GB (good)
No paging detected for 7.12GB (good)
No paging detected for 7.84GB (good)
No paging detected for 8.55GB (good)
No paging detected for 9.26GB (good)
No paging detected for 9.97GB (good)
No paging detected for 10.69GB (good)
*** PAGING DETECTED after 11.4GB ***
Allocated 729.6MB per thread (11.4GB) for 16 threads, but paging detected.
Paging detected, reducing memory usage and retrying with 98% of previous value.

Checking for virtual memory paging for 11.2GB
No paging detected for 715.0MB (good)
No paging detected for 1.40GB (good)
No paging detected for 2.09GB (good)
No paging detected for 2.79GB (good)
No paging detected for 3.49GB (good)
No paging detected for 4.19GB (good)
No paging detected for 4.89GB (good)
No paging detected for 5.59GB (good)
No paging detected for 6.28GB (good)
No paging detected for 6.98GB (good)
No paging detected for 7.68GB (good)
No paging detected for 8.38GB (good)
No paging detected for 9.08GB (good)
No paging detected for 9.77GB (good)
No paging detected for 10.47GB (good)
*** PAGING DETECTED after 11.2GB ***
Allocated 715.0MB per thread (11.2GB) for 16 threads, but paging detected.
Paging detected, reducing memory usage and retrying with 98% of previous value.

Checking for virtual memory paging for 10.95GB
No paging detected for 700.7MB (good)
No paging detected for 1.37GB (good)
No paging detected for 2.05GB (good)
No paging detected for 2.74GB (good)
No paging detected for 3.42GB (good)
No paging detected for 4.11GB (good)
No paging detected for 4.79GB (good)
No paging detected for 5.47GB (good)
No paging detected for 6.16GB (good)
No paging detected for 6.84GB (good)
No paging detected for 7.53GB (good)
No paging detected for 8.21GB (good)
No paging detected for 8.90GB (good)
No paging detected for 9.58GB (good)
No paging detected for 10.26GB (good)
No paging detected for 10.95GB (good)
Allocated 700.7MB per thread (10.95GB) for 16 threads, reverifying paging behavior...
Done determining pageable memory.
NOTE: Avoid starting applications while tests are running; system response will be very sluggish.

Memory usage per thread: 700.7MB
Volumes to test: "OS"
Read-only: false

Creating 16 CPU thread(s) at 100% utilization, each consuming 700.7MB for a total memory use of 10.95GB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Starting...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 started.
Waiting for all threads to start...
All threads were started.
Thread 0 started OK.
Thread 1 started OK.
Thread 2 started OK.
Thread 3 started OK.
Thread 4 started OK.
Thread 5 started OK.
Thread 6 started OK.
Thread 7 started OK.
Thread 8 started OK.
Thread 9 started OK.
Thread 10 started OK.
Thread 11 started OK.
Thread 12 started OK.
Thread 13 started OK.
Thread 14 started OK.
Thread 15 started OK.
16 cpu threads started successfully using a total of 10.95GB of memory, to be accessed continually.


=====> Use ctrl-C to stop <=====
Note: speeds denote memory copying speed (memmove); multiply by 2 for total bandwidth.

Read-write mode for volume "OS" using temp file __DiskWhacker__217.6
10s: 56754.4MB @ 9529 MB/sec (best)
20s: 58155.8MB @ 10355 MB/sec (best)
30s: 64461.8MB @ 10260 MB/sec
40s: 63060.5MB @ 10225 MB/sec
50s: 63060.5MB @ 10226 MB/sec
60s: 61659.1MB @ 10316 MB/sec
Maximum bandwidth so far: 10355 MB/sec
70s: 65863.2MB @ 10184 MB/sec
80s: 62359.8MB @ 10174 MB/sec
90s: 63060.5MB @ 10410 MB/sec (best)
100s: 65863.2MB @ 10218 MB/sec
110s: 61659.1MB @ 10421 MB/sec (best)
120s: 64461.8MB @ 10324 MB/sec
Maximum bandwidth so far: 10421 MB/sec
130s: 65162.5MB @ 10274 MB/sec
140s: 60958.4MB @ 10359 MB/sec
150s: 64461.8MB @ 10308 MB/sec
160s: 63761.1MB @ 10267 MB/sec
170s: 62359.8MB @ 10251 MB/sec
180s: 60958.4MB @ 10317 MB/sec
Maximum bandwidth so far: 10421 MB/sec
190s: 65162.5MB @ 10294 MB/sec
200s: 63761.1MB @ 10231 MB/sec
210s: 63060.5MB @ 10214 MB/sec
220s: 63060.5MB @ 10254 MB/sec
230s: 63060.5MB @ 10168 MB/sec
240s: 62359.8MB @ 10298 MB/sec
Maximum bandwidth so far: 10421 MB/sec
250s: 65162.5MB @ 10366 MB/sec
260s: 63060.5MB @ 10241 MB/sec
270s: 62359.8MB @ 10221 MB/sec
280s: 62359.8MB @ 10233 MB/sec
290s: 62359.8MB @ 10236 MB/sec
300s: 65162.5MB @ 10227 MB/sec
Maximum bandwidth so far: 10421 MB/sec
Memory bandwidth: 10421 MB/sec
Waiting for tasks to exit...16...16...15...15...14...13...12...11...11...9...7...6...4...2...done.
Waiting for DiskWhackerTask for volume "OS" to exit...done.
Test duration: 300.0 seconds...

Command "run-stress-test" executed in 390.66 seconds.

====================
16 gb memory test
====================

dlt run-stress-test -d 5M -v OS

diglloydTools 1.1.0 64-bit Copyright 2006-2008 diglloyd, Inc. All Rights Reserved.
Thursday, March 12, 2009 1:02:40 PM PT
Physical memory (MB): 16384

********************************** Stress Test *********************************
System memory: 16GB
Test duration: 5m
CPU percent: 100% (per cpu core)
Num CPU threads: 16
Memory per thread (requested): 972.8MB

==> Determining amount of non-pageable memory
(this phase can take several minutes before stress-testing begins)


Checking for virtual memory paging for 15.2GB
No paging detected for 972.8MB (good)
No paging detected for 1.90GB (good)
No paging detected for 2.85GB (good)
No paging detected for 3.80GB (good)
No paging detected for 4.75GB (good)
No paging detected for 5.70GB (good)
No paging detected for 6.65GB (good)
No paging detected for 7.60GB (good)
No paging detected for 8.55GB (good)
No paging detected for 9.50GB (good)
No paging detected for 10.45GB (good)
No paging detected for 11.4GB (good)
No paging detected for 12.3GB (good)
No paging detected for 13.3GB (good)
No paging detected for 14.2GB (good)
*** PAGING DETECTED after 15.2GB ***
Allocated 972.8MB per thread (15.2GB) for 16 threads, but paging detected.
Paging detected, reducing memory usage and retrying with 98% of previous value.

Checking for virtual memory paging for 14.9GB
No paging detected for 953.3MB (good)
No paging detected for 1.86GB (good)
No paging detected for 2.79GB (good)
No paging detected for 3.72GB (good)
No paging detected for 4.65GB (good)
No paging detected for 5.59GB (good)
No paging detected for 6.52GB (good)
No paging detected for 7.45GB (good)
No paging detected for 8.38GB (good)
No paging detected for 9.31GB (good)
No paging detected for 10.24GB (good)
No paging detected for 11.2GB (good)
No paging detected for 12.1GB (good)
No paging detected for 13.0GB (good)
No paging detected for 14.0GB (good)
No paging detected for 14.9GB (good)
Allocated 953.3MB per thread (14.9GB) for 16 threads, reverifying paging behavior...
Done determining pageable memory.
NOTE: Avoid starting applications while tests are running; system response will be very sluggish.

Memory usage per thread: 953.3MB
Volumes to test: "OS"
Read-only: false

Creating 16 CPU thread(s) at 100% utilization, each consuming 953.3MB for a total memory use of 14.9GB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Starting...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 started.
Waiting for all threads to start...
All threads were started.
Thread 0 started OK.
Thread 1 started OK.
Thread 2 started OK.
Thread 3 started OK.
Thread 4 started OK.
Thread 5 started OK.
Thread 6 started OK.
Thread 7 started OK.
Thread 8 started OK.
Thread 9 started OK.
Thread 10 started OK.
Thread 11 started OK.
Thread 12 started OK.
Thread 13 started OK.
Thread 14 started OK.
Thread 15 started OK.
16 cpu threads started successfully using a total of 14.9GB of memory, to be accessed continually.


=====> Use ctrl-C to stop <=====
Note: speeds denote memory copying speed (memmove); multiply by 2 for total bandwidth.

Read-write mode for volume "OS" using temp file __DiskWhacker__158.7
10s: 33365.3MB @ 6676 MB/sec (best)
20s: 51477.9MB @ 8196 MB/sec (best)
30s: 47664.7MB @ 8897 MB/sec (best)
40s: 48618.0MB @ 8537 MB/sec
50s: 49571.3MB @ 8233 MB/sec
60s: 50524.6MB @ 8667 MB/sec
Maximum bandwidth so far: 8897 MB/sec
70s: 48618.0MB @ 8864 MB/sec
80s: 48618.0MB @ 8729 MB/sec
90s: 45758.2MB @ 9010 MB/sec (best)
100s: 47664.7MB @ 8925 MB/sec
110s: 51477.9MB @ 8666 MB/sec
120s: 49571.3MB @ 8842 MB/sec
Maximum bandwidth so far: 9010 MB/sec
130s: 50524.6MB @ 8414 MB/sec
140s: 45758.2MB @ 8766 MB/sec
150s: 49571.3MB @ 8762 MB/sec
160s: 49571.3MB @ 8420 MB/sec
170s: 47664.7MB @ 9024 MB/sec (best)
180s: 51477.9MB @ 8774 MB/sec
Maximum bandwidth so far: 9024 MB/sec
190s: 47664.7MB @ 8833 MB/sec
200s: 53384.5MB @ 8805 MB/sec
210s: 43851.6MB @ 8883 MB/sec
220s: 50524.6MB @ 8630 MB/sec
230s: 49571.3MB @ 8445 MB/sec
240s: 50524.6MB @ 8457 MB/sec
Maximum bandwidth so far: 9024 MB/sec
250s: 45758.2MB @ 8835 MB/sec
260s: 49571.3MB @ 8457 MB/sec
270s: 49571.3MB @ 8900 MB/sec
280s: 47664.7MB @ 8327 MB/sec
290s: 48618.0MB @ 8614 MB/sec
300s: 51477.9MB @ 8448 MB/sec
Maximum bandwidth so far: 9024 MB/sec
Memory bandwidth: 9024 MB/sec
Waiting for tasks to exit...16...16...16...16...16...16...15...15...15...14...14...13...13...12...11...10...9...9...6...5...4...1...done.
Waiting for DiskWhackerTask for volume "OS" to exit...done.
Test duration: 300.0 seconds...

Command "run-stress-test" executed in 383.93 seconds.
 
I never fully understood how you could have triple channel and then a single channel that runs slower. I guess even if that is the case, you'll have to wait for whatever processes is running in the slower ram to finish before moving on to the next operation.

Usually RAM configurations default to the lowest denominator. I would of figured that it would just default to dual-channel since it's 4 slots of ram, while would theoretically be 33% slower. Although many hardware review sites have seen minimal impact of triple-channel versus dual-channel.

Each processor's memory controller connects to 3 different channels. When all 3 are populated you get the full triple channel bandwidth. Each channel also supports 3 DIMMs but Apple chose to only support more than one DIMM on the first channel.

Ideally, Apple should have had 6 DIMM slots per CPU. Maybe in the next revision we will actually get a case redesign to accomodate a wee bit more space for more RAM.

Yes they should have.
 
thanks for the info Boneoh- if you find that original info for the 6gig and you can run it against 8gig that would be much helpful too :)
 
It would be interesting to see the 2008 3.2GHz MP configured and tested with 6 x 2GB ram as well.
 
I get that, i just wanna see what kinda hit that relates to in performance. If it doesnt end up being a big deal then maybe i just take a couple months dealing with dual-channel and then when i decide to upgrade ram later on to 3-channel i dont need to ditch any of the sticks currently in the system. I wish barefeats had included the 8gig spec in that bench

Revised graphs now up on Barefeats with full RAM breakdown (inc 8gig)
 
neh04_293.gif


neh04_226.gif


This app runs the same on 4 cores as 8 cores (at 8GB they are within 10%)... it seems it's memory limited not CPU limited. I'm mildly curious why the benchmark would suffer at 14GB but not 13GB.
 
aah very good thats what i was looking for. So 8gigs is still a safe bet it looks like :)
 
how did you have after effects configured in that test, assuming you were running CS4?

also, today is the day to decide... 12gb or 16gb ($75 more). what do you guys think?

i'm inclined to go with the 12 and leave a few slots open for 4gb sticks when those become somewhat reasonably priced.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.