New cost-effective DDR5 memory 'HUDIMMs' show around 50% reduction in throughput with single subchannel — Two HUDIMMs are as fast as a single stick of regular DDR5 RAM
Turns out, halving the bandwidth... halves the bandwidth.
A couple of days ago, Intel, TeamGroup and ASRock came together to unveil the "HUDIMM" spec for DDR5 RAM. HUDIMM use a single 32-bit subchannel instead of populating a 64-bit wide bus with two 32-bit channels. This effectively cuts bandwidth and capacity in half but allows for cheaper DDR5 that uses less ICs per stick. Today, new testing done by HKEPC, with the help of Asus, confirms exactly that — HUDIMM will incur an almost 50% bandwidth penalty, reducing performance significantly.
First things first, HKEPC did not get their hands on an actual retail HUDIMM kit manufactured by TeamGroup; instead, they used standard DDR5 RAM but taped half of the contact points. This allowed for one of the 32-bit subchannels to become unrecognizable, hence simulating HUDIMM. A member of Asus' R&D team has already tried this before the announcement, and we mentioned it in our previous coverage.
This new testing is more substantiated and was done on an Asus ROG Maximum Z890 Extreme motherboard, using an Intel Core Ultra 9 285K. The outlet "matched the BIOS that supports HUDIMM modules" because, unlike a retail 1x 32-bit stick, the modified 2x 32-bit RAM's SPD will still tell the memory controller it's supposed to have a 64-bit wide bus. The PC will fail to initialize (POST) otherwise and be stuck with training errors.
We start with a single rank 16 GB 7,200 MT/s stick that showed up as 8 GB. In AIDA64, it achieved read speeds of 32,447 MB/s, write speeds of 25,195 MB/s, and copy speeds of 26,894 MB/s, with an 87.7 ns latency. In contrast, the same stick when untaped hit 58,913 MB/s read, 48,800 MB/s write, and 52,648 MB/s copy speeds. That's essentially double the throughput across the board, but latency was the same at 85.7 ns.
Metric | 2x 32-bit 16 GB (Regular DDR5) | 1x 32-bit 8 GB (HUDIMM) | HUDIMM Performance |
|---|---|---|---|
Read Speeds | 58,913 MB/s | 32,447 MB/s | -44.92% |
Write Speeds | 48,800 MB/s | 25,195 MB/s | -48.37% |
Copy Speeds | 52,648 MB/s | 26,894 MB/s | -48.92% |
Latency | 85.7 ns | 87.7 ns | - |
As expected, disabling one of the 32-bit subchannels slashes the numbers in half pretty consistently. You get to build cheaper sticks that require only 4 ICs instead of the usual 8 for a 16 GB DIMM, but it clearly comes at a cost. The standard 16 GB stick is almost at 60 GB/s of effective bandwidth while the simulated 8 GB HUDIMM stick only reaches 32 GB/s. That's the kind of discrepancy you'll notice.
Switching gears to a dual channel setup, HKEPC put 2x 16 GB 7,200 MT/s sticks on the motherboard, which showed 32 GB in the standard config, but only 16 GB when taped. The same story follows; half of the bandwidth is gone when simulating HUDIMM. We drop from 106 GB/s read speeds to just 58 GB/s, the write speeds go from 93 GB/s to 48 GB/s, and the copy speeds fall from 97 GB/s to 51 GB/s. The latency remained identical.
Metric | 2x 32-bit 32 GB (Regular DDR5) | 1x 32-bit 16 GB (HUDIMM) | HUDIMM Performance |
|---|---|---|---|
Read Speeds | 106,200 MB/s | 58,928 MB/s | -44.51% |
Write Speeds | 93,235 MB/s | 48,461 MB/s | -48.02% |
Copy Speeds | 97,552 MB/s | 51,473 MB/s | -47.24% |
Latency | 86.4 ns | 86.5 ns | - |
The HUDIMM numbers here basically match the performance of a regular 16 GB stick running in single channel, which is to be expected. It's simple math, really. Across the board, we're just halving the bandwidth and capacity just to be able to make cheaper DDR5. The performance hit is significant, but since HUDIMM is aimed at budget gamers and business users, perhaps the tradeoff will be worthwhile for some.
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
One claim from the announcement that HKEPC didn't check was asymmetric dual channel support — combining HUDIMM with regular DDR5 with 2x 32-bit subchannels is supposed to drastically improve performance. ASRock said that using an 8 GB HUDIMM stick with a standard 16 GB stick nets more bandwidth than a single 24 GB UDIMM (despite having the same capacity). The 24 GB stick on its own is apparently more expensive to manufacture, too, so this is a sort of "best-of-both-worlds" pitch.
Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Hassam Nasir is a die-hard hardware enthusiast with years of experience as a tech editor and writer, focusing on detailed CPU comparisons and general hardware news. When he’s not working, you’ll find him bending tubes for his ever-evolving custom water-loop gaming rig or benchmarking the latest CPUs and GPUs just for fun.
-
hotaru251 which again they made solution to soemthing that wasnt a problem.Reply
spending more for 2 sticks of hudimm than a single stick of udimm was stupid and waste of time and resources. -
evermorex76 I assume the reasoning here is that the higher density chips are cheaper to make even at twice the capacity, so 8GB with 4 chips is cheaper than 8GB with 8 chips? And the ones that would use these are those that are more price-sensitive than performance-hungry. A single 16GB 64-bit stick might also be slightly more than two 8GB 32-bit sticks, if the PCB and assembly cost isn't a huge percentage of the total, so you could get the same performance overall (roughly) for a lot less money, but sacrifice the option to just add another module to get double the capacity on a 2-slot board, again not being important at the low end. A 4-slot board would have options though, allowing you to go cheap at the start then upgrade when RAM is less expensive without having to throw out what you have. (I doubt you can mix 32- and 64-bit modules on the same channel, making the controller work with both at once on that channel.)Reply
Mixing 8GB 32- and 16GB 64-bit modules to get 96-bit would be effective but only for 16GB of the RAM. Same as two sizes that are both 64-bit, though with less loss for data that goes into the single-channel address range (as long as the 64-bit is the larger one; if it's the smaller, the performance drop would be huge). You would ideally still want 8GB in both channels.
I hadn't even realized or thought about the controllers still working with bonded 32-bit sub-channels. Just subconsciously assumed it was a single 64-bit now, and it seems like that would have reduced complexity and allowed higher performance. I remember when dual-channel was still newish and some chipsets (nForce) had the option of bonding them as a single 128-bit bus or operating as two independent 64-bit busses so that latency from the IGP RAM usage wouldn't delay the CPU, which helped a lot with integrated graphics as the CPU and IGP weren't using the same channel. Even with half the channel-width it allowed the CPU to maintain performance in most cases because it wasn't waiting for IGP traffic, and the CPU didn't gain that much with more width. It also allowed higher overclocking.
I think this is a false economy though, and bad for consumers overall. "Average" buyers will see a lower price (which in normal times wouldn't be that large, but would be significant during times like now with RAM prices blown up; the lower price will only be in comparison to what it could be with today's RAM prices, not what it ought to be normally) but they won't realize they're getting half the performance that they could have, or limiting their upgrade options. Pre-built machines won't be advertised with even small print saying "uses 32-bit memory modules". The more ethical companies might indicate they use HUDIMMs, but normal people won't know what that means, and some more knowledgeable ones might know what a DIMM is but just think HUDIMM is a newer and better version. Machines that currently use a single 64-bit module to save money might move to two 32-bit modules, giving the same performance and probably costing the same as they did before the memory price explosion, but they'll be cheaper than any that use a single 64-bit at today's prices, and way cheaper than two 64-bit modules. (Of course when the RAMpocalypse prices come back down, the 32-bit versions will also go down, so those systems using 32-bit will still be cheaper. My complaints it just that it's really only NOW during this period that the difference in price might be worth the loss of performance even to a moderately heavy user/gamer, and when prices go down they would be willing to pay the premium for dual 64-bit, but those people won't be aware they're getting dual 32-bit and losing performance and that's why the price is lower. People just reading email and web surfing won't care about anything but price at any time.)
And the RAM makers and system builders will continue making and using 32-bit modules forever, muddying the waters of the market for buyers to save a bit of money on the build side which they'll only partially pass on to the customer, so it ultimately becomes another profit-maker more than concern about customers being able to afford them. And I guarantee there will be systems being sold with a single 32-bit module at a price that isn't as much less as it ought to be for the performance loss, with only some hidden or small-print indicator in unintelligible marketing-speak to inform the consumer of what they're getting.
This is worse than CAMM RAM, which I think is bad because with that you will always and forever be forced to replace ALL your RAM if even one chip goes bad or you want to upgrade. I think they could still improve performance without changing the form factor to that, and any cost savings aren't worth the consequences of forced dual-channel modules except for people who would never upgrade and are in the (admitted majority) group that never have a failure. -
ezst036 Reply
"And capacity"????Admin said:This effectively cuts bandwidth and capacity in half but allows for cheaper DDR5 that uses less ICs per stick.
I must be reading the word capacity wrong because if a 16GB UDIMM is 16GB and a 16GB HUDIMM is 16GB then what is the capacity change?
Otherwise they found a way to bring us back to SIMMs. Hoooray! :sick:
Using less ICs per stick would indeed reduce prices and make DDR5 cheaper in the midst of manufacturing woes. Mission accomplished. -
8086 This is a terrible idea that should die, but I got a feeling OEMs will love them due to their lesser performance which forces the non-tech person to upgrade much sooner than would be necessary.Reply
Similar to how some OEMs will solder 32gb of ram on to one single channel and leave no option to populate the second ram channel. -
thestryker Reply
Existing 8GB modules are also 4 packages, but they're 16-bit instead of 8-bit. My assumption is that this move is more about lack of availability of 16-bit packages than any other reasoning.evermorex76 said:I assume the reasoning here is that the higher density chips are cheaper to make even at twice the capacity, so 8GB with 4 chips is cheaper than 8GB with 8 chips? -
wwenze1 The proposed 96-bit doesn't make much business sense either. 64-bit is tolerable, 128-bit is gamer standard, why create 96-bit using multiple SKUs for 75% performance of 128-bit at a cost that is definitely higher than 75% of 128-bit? Not forgetting we're talking not just bus width but also capacity.Reply
If in the future people create a new ecosystem of multiples of 32-bits, then, sure, go nuts with 96-bits. But right now it's just awkward.
In the future when each 16GB = 32-bit, then we need this to help keep costs down. Which may not be too far off.
Good to test, it could have been worse due to bugs etc.palladin9479 said:In today's news scientists discover water is wet. -
bit_user Reply
Literally the only thing they could've tried where the outcome wasn't completely obvious!The article said:One claim from the announcement that HKEPC didn't check was asymmetric dual channel support
I mean, if you were going to try one thing, that should be it! -
bit_user Reply
I think it might be about wanting to pair 4 GB with 8 GB DIMMs, not just for better performance, but perhaps also because 16 Gb DRAM chips with 16-bit interfaces might be more plentiful than 24 Gb chips with 16-bit interfaces.wwenze1 said:The proposed 96-bit doesn't make much business sense either.
Or, it could be that 16-bit packages are disproportionately available, since they have no application in servers?thestryker said:My assumption is that this move is more about lack of availability of 16-bit packages than any other reasoning.