*Fresh* DDR5 Benchmark Results

We're Almost There

Picking up from my last year's rant about Dual DDR5 not being up-to-speed with Quad DDR4, I was definitely not wrong, since achieving 120-135GB/s on Quad DDR4 setups was relatively trivial, especially on X299X where we could get lots of ram, at very high speeds, running flawlessly on 4 channel configurations.

When DDR5 first came out, it also came with much needed features, and now, finally, we have ECC.

ECC, why not?

You know the reason we didn't have (ECC) Error-Correcting Code on DDR4/DDR3/DDR2 for mainstream PC's? There is one reason. And the reason is Intel's Artificial Market Segmentation Yup, you can blame the blue team on that one, 100%.

In case you want to read more, you can: read from Linus Torvalds himself.

We can't leave without quoting the article above:

Intel's Artificial Market Segmentation

Intel's segmentation was not only for ECC, they lock overclocking for non-K SKU's. They also disable hyper-threading on chips that could easily handle it and force users to buy a physical key to run VROC (Virtual Raid on CPU) on motherboards that already come with the feature built in. So, you paid 1999USD on a high end motherboard with all the features? Well, you will still have to wire a couple bucks more to Intel and buy this plastic thing so you'll be able to use a feature that your motherboard already has, it is just soft locked. Many consumers were shocked when they figured out their RAIDs were not working because they lacked a 'physical-key' and many, including me, had to wait up to two months to have them delivered.

JEDEC to the Rescue

When JEDEC was establishing the DDR5 standard, the inclusion of on-die ECC (Error-Correcting Code) was not optional, it was mandatory. If you are not familiar with ECC, it is a feature designed to continuously monitor data stored in RAM for any potential errors. The primary motivation behind this mandate was to increase the reliability of DDR5 memory, especially when dealing with high memory density configurations. on-die ECC is a standard feature in all DDR5 modules. It is definitely a win for all of us.

Final Considerations

As of 2024, DDR5 is a little more mature now, we do have better speeds, prices did decrease a bit, availability is OK. If we go back, at the end of DDR3 lifetime, we had extremely fast DDR3 chips, it took a while for DDR4 to catch up, and I knew the same would happen to DDR5, it is not my first rodeo. But then, I wish that the timings (most notably CL and tRCD) were a little bit lower, but we can't have it all. Overall I am happy and I think we'll see 9000MHz chips soon!

Test System Specs

Results

Ending Thoughts

Your results might not be exactly the same, so take this into account, but it already serves as a good starting point for what you can expect if you are thinking about upgrading to DDR5. As of now I don't have a 7950X3D, so I am in the dark when it comes to AMD's numbers, so take my results with a grain of salt if you're considering an AM5 build.

The methodology was simple, I kept the same timings (40-40-40-77), ran the test four times, took the smallest value because I don't want to sound optimistic, restarted and changed the Memory Frequency. Anything above 6800MHz is already considered an overclock for my memory chips, but this Hynix Die for DDR5 is the equivalent of the already famous DDR4 Samsung B-Die, it does overclock pretty well!

Good luck, and feel free to show me your results (ง'̀-'́)ง !

Sidenote

It's worth noting that discussions about Intel's market segmentation are relatively scarce, both among public figures and in general discourse. It's essential to understand that my aim is not to demonize Intel, but rather to highlight concerns about their aggressive market segmentation, which can have negative implications for both consumers and developers. This isn't a witch hunt; it's a call for constructive change.

Intel, like any for-profit company, seeks to maximize its revenue. However, when their segmentation practices create difficulties for developers and users, it's important to voice these concerns. The importance of these discussions is to prevent it from happening again, take the transactional memory disaster, in this specific scenario, only a few developers (1%) who had access to Xeon's could deploy and debug the feature, and it is something that hurts Intel, Developers and Consumers! We need everyone to thrive, everyone.