Preliminary tests

First of all, we decided to evaluate performance of each configuration in a synthetic application Everest 4.6 (it's not the latest version of the popular benchmark, but real software is not updated instantly either, so these results are also very interesting, even if the version 4.6 is not optimized for Nehalem).

As we can see, high-speed memory easily outperforms our assembly operating in the 1333-CL9 mode, we have never doubted it would. Interestingly, the 160x10 mode is slower than the 133x12 mode -- we thought that they would be either identical or the former would be faster.

That's exactly what it does in the low-level write test. However, last time we already found out that this test depends much on the UnCore frequency. So practice here is in full agreement with the theory. What's more interesting, owing to the reduced latencies, high-speed memory is actually noticeably faster than the "slow" memory even at the same UnCore frequency.

That's the answer to the question why the 160x10 mode is not very fast for reading: it features higher latencies than the 133x12 mode, that is the explanation lies inside the memory controller, in its operating peculiarities. However, latencies in this case are still lower than in the 133x10 mode even with CL7, to say nothing of the "slow" CL9!

So, from the point of view of low-level utilities, high-speed memory usage is justified. All its modes are useful in their own way. Thus, one of the main conditions of any test has been met -- we'll compare objectively different things. We'll see whether this different will affect real applications using our standard test procedure (as usual, detailed test results are published in the summarized spreadsheet).

3D visualization

The fastest turned out to be the slowest. But the difference is so minuscule that they can be considered identical. Comparison with performance gains provided by the increased CPU clock rate in the boost mode (tasks in this group of tests are not very enthusiastic about more than two threads, so the frequencies grows noticeably; if you let it, of course) makes it crystal clear that there is no point in messing with memory.

3D rendering

Rendering traditionally belongs to tasks that are indifferent to memory. But we can see that its tuning allows to make up for the 80 MHz lag in processor clock rates, a very good result -- unlike the previous case, all eight threads are effective here. There may be even a little gain with the same core clock rates. Very small -- the official factory overclocking is much more efficient.

Scientific computation

Fast memory brings some performance gains once again -- three points between 1600-CL8 and 1333-CL7 with the equally-clocked processors. Things are not that bad even when processors operate at different frequencies. However, Turbo Boost again goes far beyond these limits.

Bitmap processing

This picture is similar to what we saw on the first diagram -- fast memory does not necessarily lead to maximum operating speed. It's generally useless. However, some Photoshop tests are quite responsive to memory size instead of memory speed.

Write a comment below. No registration needed!