Memory Bandwidth and Scaling

Everyone should already know that memory bandwidth improves with increases in memory speed and reductions in memory timings. To better understand the behavior of AM2 and Core 2 Duo memory bandwidth we used SiSoft Sandra 2007 Professional to provide a closer look at memory bandwidth scaling.


The most widely reported Sandra score is the Standard or Buffered memory score. This benchmark takes into account the buffering schemes like MMX, SSE, SSE2, SSE3, and other buffering tools that are used to improve memory performance. As you can clearly see in the Buffered result the AM2 on-chip memory controller holds a huge lead in bandwidth over Core 2 Duo. At DDR2-800 the AM2 lead in memory bandwidth is over 40%.

As we have been saying for years, however, the Buffered benchmark does not correlate well with real performance in games on the same computer. For that reason, our memory bandwidth tests have always included an UNBuffered Sandra memory score. The UNBuffered result turns off the buffering schemes, and we have found the results correlate well with real-world performance.


The Intel Core 2 Duo and AMD AM2 behave quite differently in UNBuferred tests. In these results AM2 and Core2 Duo are very close in memory bandwidth - much closer than in Standard tests. Core 2 Duo shows wider bandwidth below DDR2-800, but this will likely change when the AM2 controller matures and supports values below 3 in memory timings as the Core 2 Duo currently supports.

The Sandra memory score is really made up of both read and write operations. By taking a closer look at the Read and Write components we can get a clearer picture of how the two memory controllers operate. Everest from Lavalys provides benchmarking tools that can individually measure Read and Write operations.


The READ results are particularly interesting, since you can see that the READ component of Core 2 Duo performance is much larger than the WRITE results on Core 2 Duo. This is the result of the intelligent read-aheads in memory which Intel has used to lower the apparent latency of memory on the Core 2 Duo platform. Actual READ performance on Core 2 Duo now looks almost the same as AM2 to DDR2-533. AM2 starts pulling away in READ at DDR2-677 and has a slightly steeper increase slope as memory speed increases. The increases in READ speed in Core 2 Duo are a result of the intelligent read-aheads in memory. Performance without this feature would show Core 2 Duo much slower in READ operations than AM2.


This is most clearly illustrated by looking at Everest Write scores. Memory read-ahead does not help when you are writing memory, so core 2 Duo exhibits much lower WRITE performance than AM2 as we would expect. This means if all else were equal (and it isn't) the AM2 would perform much better in Memory Write tasks. Surprisingly the WRITE component of Core 2 Duo appears a straight line just below 5000 MB/s. AM2 starts at 5900 at DDR2-400 and WRITE rises to around 8000MB/s at DDR2-667. Write then appears to level off, with higher memory speeds having little to no impact on AM2 WRITE performance.

A Closer Look at Latency and Scaling Stock Performance Comparison
Comments Locked

118 Comments

View All Comments

  • zsdersw - Tuesday, July 25, 2006 - link

    I care about people making blatantly false claims.
  • Wesley Fink - Tuesday, July 25, 2006 - link

    We used the SAME memory timings on both processors if they were available. For the DDR2-1067 and DDR2-800 they were exactly the same on both processors in all tests, which is why they were used for our 2.93GHz comparison. At DDR2-667 and below, the Core 2 Duo could support timings like 3-2-2, where AM2 only supports 3-3-3. This article was to evaluate memory performance, so we did everything possible to keep all variables the same.

    Memory timings were DDR2-400 - 3-2-2-5; 533 - 3-2-2-6; 667 - 3-2-3-7; 800 - 3-3-3-9; 1067 - 4-3-4-11; DDR2-1112 - 5-4-5-14.
  • duploxxx - Wednesday, July 26, 2006 - link

    well those cas settings were to be expected when you saw the memory performance chart.
    you just killed the performance after ddr2 800 cas4 is ok but the minor step you have from ddr 1067 to ddr 1112 and again 1 cas higher is the end of good performance. so the memory of the fx to get to 2.9 was? that explains probably the lower performance vs the linear performance increase in the memory.....
  • Bingo13 - Wednesday, July 26, 2006 - link

    quote:

    you just killed the performance after ddr2 800 cas4 is ok but the minor step you have from ddr 1067 to ddr 1112 and again 1 cas higher is the end of good performance.


    The timings utilized by AnandTech were about the best you will see with current DDR2 memory. They did not kill the performance, the memory capability is what limited the testing. Tell me, where can you buy DDR2 that will do 3-3-3-9 at 1067. This review was more than fair in the settings it utilized for the tests and it took $450 memory to do it.
  • duploxxx - Thursday, July 27, 2006 - link

    yes i know but you don't get my point...
    we know fx34 will be 3.0 so its stupid to try and get an fx at 2,93.
    run an fx at 3.0 (multiplier change) with the nice cas3-3-3 like you did and the performance will be way better. now you killed the performance (speedbump cpu and memory) by dropping the cas to 4
  • Wesley Fink - Wednesday, July 26, 2006 - link

    DDR2-800 was 3-3-3-9 2.2V. The FX at 2.93GHz was running DDR2-1067 at 4-3-4-11 2.2V.
  • Gary Key - Tuesday, July 25, 2006 - link

    We had a slight change in pages after the article went live. Page seven now represents stock memory performance on each platform with page eight now showing the overclocked FX62 (11x266, 2.93GHz) compared to the X6800 (11x266, 2.93GHz). A comparison that is quite revealing based upon numerous comments about what the expected results of running a high memory strap and low latency settings on the AM2 platform would even out the performance differences between the two platforms.
  • Wesley Fink - Tuesday, July 25, 2006 - link

    We were moving pages around as it posted. The page references should now be correct. The page that AMD fans will likely hate is now page 8.

Log in

Don't have an account? Sign up now