Cache Latency:
As you’ve seen from our results, AMD’s new 65 nanometre Brisbane core is ever so slightly slower than the Windsor core it is replacing. We didn’t really get much of an explanation from AMD – the company told us that the processor would perform the same as its 90nm derivative. However, while that’s true to an extent, there was a consistent pattern in our performance evaluations, whereby the Brisbane core was less than 0.5% slower virtually right across the board.
With this in mind, we had read numerous reports about the increased cache latency on the Brisbane core, but we wanted to check things out for ourselves. We took measurements using both CPU-Z’s latency add-on, and also Cachemem 2.65. Both programmes produced different results, and we weren’t entirely sure which one to believe. However, after reading a number of Brisbane previews from other publications, things started to get a bit clearer.
AMD has acknowledged that there is
increased cache latency from 12 cycles to 14 cycles on Brisbane. In addition, the company has also stated that it opted to do this as a provision for introducing larger L2 caches if its customers demand it in the future. Finally AMD's statements confirmed that we were getting some strange results with CPU-Z's latency tool, which reported that there was an increase in cache latency from 12 to 20 cycles.
Below, we’ve attached some graphs generated by Cachemem’s results – these help to show the increase in cache latency and the first graph also help to show that there’s a small increase in memory latency, too.
The dark green portion represents the L1 cache latencies - there are little to no latency differences there. The light green portion of the graph represents main memory and the mid-green portion represents L2 cache latency. In the second graph, we've removed system memory from the equation to help to highlight the L2 cache latency differences a little more prominently.
Want to comment? Please log in.