Memory Scaling on Haswell CPU, IGP and dGPU: DDR3-1333 to DDR3-3000 Tested with G.Skill
by Ian Cutress on September 26, 2013 4:00 PM ESTAs mentioned previously, real world testing is where users should be feeling the benefits of spending up to 13x on memory, rather than a synthetic test. A synthetic test exacerbates a specific type of loading to get peak results in terms of memory read/write and latency timings, most of which are not indicative of the pseudo random nature of real-world workloads (opening email, applying logic). There are several situations which might fall under the typical scrutiny of a real world loading, such as video conversion/video editing. It is at this point we consider if the CPU caches are too small and the system is relying on frequent memory accesses because the CPU cannot be fed with enough data. It is these circumstances where memory speed is important, and it is all down to how the video converter is programmed rather than just a carte blanche on all video converters benefitting from memory. As we will see in the IGP Compute section of this review, anything that can leverage the IGP cores can be a ripe candidate for increased memory speed.
Our tests in the CPU Real World section come from our motherboard reviews in order to emulate potential scenarios that a user may encounter.
USB 3.0 Copy Test with MaxCPU
We transfer a set size of files from the 120GB OCZ Vertex3 connected via SATA 6 Gbps on the motherboard to the 240 GB OCZ Vertex3 SSD with a SATA 6 Gbps to USB 3.0 converter via USB 3.0 using DiskBench, which monitors the time taken to transfer. The files transferred are a 9.2 GB set of 7539 files across 1011 folders – 95% of these files are small typical website files, and the rest (90% of the size) are precompiled installers. In an update to pre-Z87 testing, we also run MaxCPU to load up one of the threads during the test which improves general performance up to 15% by causing all the internal pathways to run at full speed.
Results are represented as seconds taken to complete the copy test, where lower is better.
The difference between the slowest and the fastest is around 2%, or 1 second in our test, making the memory have little influence over intended USB speed (at load).
WinRAR 4.2
With 64-bit WinRAR, we compress the set of files used in the motherboard review USB speed tests. WinRAR x64 3.93 attempts to use multithreading when possible, and provides as a good test for when a system has variable threaded load. WinRAR 4.2 does this a lot better! If a system has multiple speeds to invoke at different loading, the switching between those speeds will determine how well the system will do.
Up first, WinRAR 3.93, with results expressed in terms of seconds to compress. Lower is better.
Using the older version of WinRAR shows a 31% advantage moving from 1333 C9 to 3000 C12, although 2400 C9/2666 C10/2800 C11 have a good showing.
WinRAR 4.2 results next:
We see similar results with the later version of WinRAR – here having at least 1866 MHz memory gets above the grade in terms of time, lower CAS Latency helping (1866 C8 / 2133 C9 / 2400 C9 / 2666 C11)
FastStone Image Viewer 4.2
FastStone Image Viewer is a free piece of software I have been using for quite a few years now. It allows quick viewing of flat images, as well as resizing, changing color depth, adding simple text or simple filters. It also has a bulk image conversion tool, which we use here. The software currently operates only in single-thread mode, which should change in later versions of the software. For this test, we convert a series of 170 files, of various resolutions, dimensions and types (of a total size of 163MB), all to the .gif format of 640x480 dimensions. Results shown are in seconds, lower is better.
FastStone is purely a CPU limited benchmark, with little variation and no trend in the results. Discrepancies are part of the statistical variation expected with any result.
Xilisoft Video Converter 7
With XVC, users can convert any type of normal video to any compatible format for smartphones, tablets and other devices. By default, it uses all available threads on the system, and in the presence of appropriate graphics cards, can utilize CUDA for NVIDIA GPUs as well as AMD WinAPP for AMD GPUs. For this test, we use a set of 33 HD videos, each lasting 30 seconds, and convert them from 1080p to an iPod H.264 video format using just the CPU. The time taken to convert these videos gives us our result in seconds, where lower is better.
Similar to WinRAR, to avoid the ultra-slow speeds, anything above 1866 MHz seems to be the right way to go here.
Video Conversion - x264 HD Benchmark
The x264 HD Benchmark uses a common HD encoding tool to process an HD MPEG2 source at 1280x720 at 3963 Kbps. This test represents a standardized result which can be compared across other reviews, and is dependent on both CPU power and memory speed. The benchmark performs a 2-pass encode, and the results shown are the average frame rate of each pass performed four times. Higher is better this time around.
The higher frequency memory performs the best, but to get at least 5% speed up, DDR3-1866 comes along again.
For whatever reason the 1333 C9 and 3000 C12 get a bad showing, but it seems as long as we avoid 1333 C9, any speed is reasonable for a 5-6% increase.
TrueCrypt v7.1a AES
One of Anand’s common CPU benchmarks is TrueCrypt, a tool designed to encrypt data on a hard-drive using a variety of algorithms. We take the program and run the benchmark mode using the fastest AES encryption protocol over a 1GB slice, calculating the speed in GB/s. Higher is better.
Similar to FastStone, there is nothing to differentiate the results. The only oddball here is technically our slowest memory speed: 1333 C9.
89 Comments
View All Comments
ShieTar - Friday, September 27, 2013 - link
I think you would have to propose a software benchmark which benefits from actually running from a Ramdisk. Testing the RD itself with some kind of synthetic HD-Benchmark will not give you much different results than a synthetic memory benchmark, unless the software implementation is rubbish.So if you want to see this happen, I suggest you explain to everybody what kind of software you use in combination with your Ramdisk, and why it benefits from it. And hope that this software is sufficiently relevant to get a large number of people interested in this kind of benchmark.
ShieTar - Friday, September 27, 2013 - link
Two comments on the "Performance Index" used in this article:1. It is calculated as the reverse of the actual access latency (in nanoseconds). Using the reverse of a physically meaningful number will always make the relationship exhibit much more of an "diminishing return" then when using the phyical attribute directly.
2. As no algorithm should care directly about the latency, but rather about the combined time to get the full data set it requested, it would be interesting to understand which is the typical size of a data set affecting the benchmarks indicate. If your software is randomly picking single bytes from the memory, you expect performance to only depend on the latency. On the other hand, if the software is reading complete rows (512 bytes), the bandwidth becomes more relevant than the latency.
Of course figuring out the best performance metric for any kind of review can take a lot of time and effort. But when you do a review generating this large amount of data anyways, would it be possible to make the raw data available to the readers, so they can try to get their own understanding on the matter?
Death666Angel - Friday, September 27, 2013 - link
First of all, great article and really good chart layout, very easy to read! :DBut one thing seems strange, the WinRAR 3.93 test, 2800MHz/C12 performs better than 2800MHz/C11, but you call out ...C11 in the text as performing well, even though anyone can increase their latencies without incurring stability issues (that's my experience at least). Switched numbers? :)
willis936 - Friday, September 27, 2013 - link
I too thought this was strange. You could see higher latencies clock for clock performing better which doesn't seem intuitive. I couldn't work out why those results were the way they were.ShieTar - Friday, September 27, 2013 - link
In reality, there really should be no reason why a longer latency should increase performance (unless you are programming some real-time code which depends on algorithm synchronization). Therefore it seems safe to interpret the difference as the measurement noise of this specific benchmark.Urbanos - Friday, September 27, 2013 - link
excellent article! i was waiting for one of these! great work, masterful :)jaydee - Friday, September 27, 2013 - link
Great work, I'd like to see a future article look at single-channel vs dual channel RAM in laptops/mITX/NUC configurations. With only two SO-DIMM slots, people have to really evaluate whether or not you want to fill both DIMM slots knowing you'd have to replace both of them if you want to upgrade but able to utilize the dual channels, or going with a single SO-DIMM, losing the dual channel but having an easier memory upgrade path down the road.Thanks and great work!
Hrel - Friday, September 27, 2013 - link
How do you get such nice screenshots of the BIOS? They look much nicer than when people just use a camera so what did you use to take those screenshots?merikafyeah - Friday, September 27, 2013 - link
Probably used a video capture card. These are also used to objectively evaluate GPU frame-pacing in a way that software like FRAPS cannot.Rob94hawk - Saturday, September 28, 2013 - link
Moder BIOS allow you to upload screenshots to USB. My MSI Z87 Gaming does it. No more picture taking. It's a great feature long overdue!