Gaming Performance Benchmarks: DDR5-4800

To show the performance of DDR5 memory in different configurations, we've opted for a more selective and short-form selection of benchmarks from our test suite. This includes Civilization VI, Grand Theft Auto V, and Strange Brigade (DirectX 12).

All of the tests were run with all of the memory at default (JEDEC) settings, which means DDR5-4800 CL40, regardless of the configuration, e.g, 2x16, 2x32, and 4x16 GB.

Civilization 6

Originally penned by Sid Meier and his team, the Civilization series of turn-based strategy games are a cult classic, and many an excuse for an all-nighter trying to get Gandhi to declare war on you due to an integer underflow. Truth be told I never actually played the first version, but I have played every edition from the second to the sixth, including the fourth as voiced by the late Leonard Nimoy, and it is a game that is easy to pick up, but hard to master.

Benchmarking Civilization has always been somewhat of an oxymoron – for a turn based strategy game, the frame rate is not necessarily the important thing here and even in the right mood, something as low as 5 frames per second can be enough. With Civilization 6 however, Firaxis went hardcore on visual fidelity, trying to pull you into the game. As a result, Civilization can taxing on graphics and CPUs as we crank up the details, especially in DirectX 12.

Civilization VI - 1080p Max - Average FPS

Civilization VI - 1080p Max - 95th Percentile

Civilization VI - 4K Min - Average FPS

Civilization VI - 4K Min - 95th Percentile

Despite games traditionally being a GPU bottleneck instead of a CPU/memory bottleneck, in our Civ VI testing we do find some small but statistically meaningful differences in our results. The 2 x 32 GB kits were the best of the bunch, with the Samsung 2 x 16 GB kit running slightly slower. The Samsung 4 x 16 GB kit however performed a couple of frames per second slower than the rest, coming in a bit over 3% slower than the 2 x 32 GB Samsung kit.

Grand Theft Auto V

The highly anticipated iteration of the Grand Theft Auto franchise hit the shelves on April 14th 2015, with both AMD and NVIDIA to help optimize the title. At this point GTA V is super old, but still super useful as a benchmark – it is a complicated test with many features that modern titles today still struggle with. With rumors of a GTA 6 on the horizon, I hope Rockstar make that benchmark as easy to use as this one is.

GTA doesn’t provide graphical presets, but opens up the options to users and extends the boundaries by pushing even the hardest systems to the limit using Rockstar’s Advanced Game Engine under DirectX 11. Whether the user is flying high in the mountains with long draw distances or dealing with assorted trash in the city, when cranked up to maximum it creates stunning visuals but hard work for both the CPU and the GPU.

The in-game benchmark consists of five scenarios: four short panning shots with varying lighting and weather effects, and a fifth action sequence that lasts around 90 seconds. We use only the final part of the benchmark, which combines a flight scene in a jet followed by an inner city drive-by through several intersections followed by ramming a tanker that explodes, causing other cars to explode as well. This is a mix of distance rendering followed by a detailed near-rendering action sequence, and the title thankfully spits out frame time data. The benchmark can also be called from the command line, making it very easy to use.

Grand Theft Auto V - 1080p Max - Average FPS

Grand Theft Auto V - 1080p Max - 95th Percentile

Grand Theft Auto V - 4K Low - Average FPS

Grand Theft Auto V - 4K Low - 95th Percentile

Using Grand Theft Auto V's built-in benchmark at 1080p, all of the JEDEC DDR5-4800B kits performed competitively with each other – albeit with a higher degree of variability than usual due to the nature of the game. Still, in our 4K testing, we see that Samsung 4 x 16 GB kit once again brings up the rear, this time falling behind the 2 x 32 GB kit by 7%.

Strange Brigade (DX12)

Strange Brigade is based in 1903’s Egypt and follows a story which is very similar to that of the Mummy film franchise. This particular third-person shooter is developed by Rebellion Developments which is more widely known for games such as the Sniper Elite and Alien vs Predator series. The game follows the hunt for Seteki the Witch Queen who has arisen once again and the only ‘troop’ who can ultimately stop her. Gameplay is cooperative-centric with a wide variety of different levels and many puzzles which need solving by the British colonial Secret Service agents sent to put an end to her reign of barbaric and brutality.

The game supports both the DirectX 12 and Vulkan APIs and houses its own built-in benchmark which offers various options up for customization including textures, anti-aliasing, reflections, draw distance and even allows users to enable or disable motion blur, ambient occlusion and tessellation among others. AMD has boasted previously that Strange Brigade is part of its Vulkan API implementation offering scalability for AMD multi-graphics card configurations. For our testing, we use the DirectX 12 benchmark.

Strange Brigade DX12 - 1080p Ultra - Average FPS

Strange Brigade DX12 - 1080p Ultra - 95th Percentile

Strange Brigade DX12 - 4K Low - Average FPS

Strange Brigade DX12 - 4K Low - 95th Percentile

There wasn't much difference in our testing between the 2 x 32 GB kits in our Strange Brigade Direct X12 testing. At 4K, the Samsung 4 x 16 GB once again performed slightly slower than the rest, although Samsung's 2 x 16 GB configuration performed in-line with the 2 x 32 GB kits.

CPU Performance Benchmarks: DDR5-4800 Conclusion: Two Ranks and 1DPC For Thee
Comments Locked

66 Comments

View All Comments

  • repoman27 - Thursday, April 14, 2022 - link

    But what if you left Chrome running with more than say 4 tabs open while you're gaming?

    No, I totally get what you're saying, and I'm fine with the gaming focus in general. But I'm sure there are plenty of regular visitors to this site that are more likely to be running a bunch of VMs or some other workload that might be memory bound in ways that differ from gaming scenarios.
  • RSAUser - Tuesday, April 19, 2022 - link

    A case where you care about this, you're probably a power user, at that point in time it would make sense to also test 64GB/memory exhaustion, as people are not taking old sticks with this, they'd directly buy as much as they need since DDR5.

    I can't run my work stack on 32GB RAM, and at home I often enough hit 32GB if I work on a hobby project as I like running my entire stack at once.
  • Jp7188 - Wednesday, April 13, 2022 - link

    4x16 (64GB) performed worse in every test vs. 32GB. Thats reasonable assurance mem exhaustion wasn't much of a factor.
  • Dolda2000 - Thursday, April 7, 2022 - link

    I have to admit I don't quite understand the results. I'd expect the disadvantage of 2DPC to be that they may not be able to sustain the same frequencies as 1DPC, but clearly that's not the case here since all kits are in fact running at the same frequency. That being the case, I would expect 1R, 2DPC memory to behave functionally identically to 2R, 1DPC memory, since, at least in my understanding, that's basically the same thing as far as the memory controller is concerned.

    What would account for the differences? Were the secondary and/or tertiary timings controlled for?
  • MrCommunistGen - Thursday, April 7, 2022 - link

    I've seen passing comments that running 2DPC really messes with signal integrity on current setups but didn't read into it any further. Since DDR5 has SOME built in error handling, even on non-ECC chips, it could be that signal losses are causing transmission retries which slow things down.

    Assuming that signal integrity is the issue, I'm wondering if rev2 or next gen DDR5 motherboards will try to improve the DDR5 memory traces to combat this or if it's something that needs to happen on the memory controller side.

    Also, even though the clockspeeds and primary timings are listed as being the same, the motherboard may be automatically adjusting some of the tertiary timings behind the scenes when using 2DPC, which can also have a measurable impact.
  • Dolda2000 - Thursday, April 7, 2022 - link

    >Since DDR5 has SOME built in error handling, even on non-ECC chips, it could be that signal losses are causing transmission retries which slow things down.
    I had that thought as well, but as far as I understand, DDR5's builtin error-handling is limited entirely to what happens on the die. I don't think there are any error-handling mechanisms on the wire that would allow the memory system to detect errors in transfer and retransmit.
  • thomasg - Thursday, April 7, 2022 - link

    As far as I know, there are no error correction techniques (such as forward error correction) used for the transmission paths of DDR ram, apart from ECC, thus there are no automatic retransmissions.

    The reason why frequencies or timings will suffer for multiple DIMMs per channel may be as simple as signal runtime.

    Electrical signals theoretically travel at the speed of light, but high frequency signals exhibit significant propagation delay, depending on trace design and PCB material. About half the speed of light (~150,000 km/s) is a fair assumption for typical PCB traces with DIMM sockets.

    With DDR5-4800, we're talking about clock cycles of 2400 MHz, which translates to 1 cycle per 400 femtoseconds.
    In 400 femtoseconds, the electrical high-frequency signal can travel 6 centimeters.
    Thus, with 3 centimeters longer traces between DIMM_A and DIMM_B their signals would be 180°out of phase.
    Since we're talking DDR, the rising and falling edge of the clock is used to transmit data, which means the signal timings need to be a lot tighter than 180˚, likely below 90˚, which limits the difference to 1.5 cm.

    It's not hard to imagine that this is a significant constraint to PCB layout.
    Traces can be length matched, but with wide parallel channels (64/72 traces), this is very tricky and cannot be done exactly, as it would be for narrower channels (i.e. 4 or 8 traces).

    As you might have noticed, I'm a radio guy and don't have the slightest clue about DDR memory, so take this with a grain of salt.
  • repoman27 - Friday, April 8, 2022 - link

    Just to add a few grains of salt...

    DDR5 actually does support cyclical redundancy check (CRC) for read and write operations.

    Depending on the material used for the PCB, the signal speed for microstrips might be slightly better than 1/2 c, maybe closer to 1/1.7 c or 58.5% of the speed of light.

    And according to my calculator at least, 1 ÷ 2,400,000,000 = 0.000000000416667 = 416.667 picoseconds for the unit interval.

    And not to downplay the issues you point out in designing DDR5 memory systems, but Alder Lake also supports PCI Express Gen5, which involves routing 64 traces operating at 16.0 GHz for an x16 slot. Serial point-to-point using differential signaling, so not the same thing, but still bonkers nonetheless.
  • Jp7188 - Wednesday, April 13, 2022 - link

    Correct me if I'm wrong, but crc without fec = chance of retransmission = increased latency?
  • repoman27 - Thursday, April 14, 2022 - link

    Yes, but if your BER is even close to reasonable, the additional latency from retries should be negligible. And it's not like ECC or FEC are exactly free. You want to do whatever you can to keep the error rate within acceptable tolerances before resorting to the additional overhead / complexity of error correction.

Log in

Don't have an account? Sign up now