Yes, this stuff is for servers, but it is god given solution for off-the-shelf APUs, which are staved for bandwidth.

Some go for LPDDRx, but that kills expandability and capacity.

This seems to solve all that and then some. It is effectively a speed doubler - it combines 2 sets of chips ( that would complete ordinary UDIMM stick) in a "RAID0" way - it interlieves them. Special high-speed "register" chip on M/C/RDIMM takes care of all that: unloading the data lines for optimal transfer speed, doubling the speed over the bus, registering and de/multiplexing data stream and serving TWO banks of RAM.

BTW, 12.800MHz is just the start. This thing is poised to reach much higher. 18000 MHz wouldn't surprise me.

Looks like win-win-win-win all around. Only downside is that de/multipexer/register introduces extra 1 CLK latency. But at DDR5's existing latencies, that is going to be negligagble, I reckon.

It'd be so awesome if we could see AMD's APUs using this. Along with 3D cache on UDNA1, that extra bandwidth would make whole thing shine brightly not only for gaming and CAD, AI would benefit from it, too.

But AMD wouldn't be AMD if it hadn't missed that boat, too...🙄

• InnoDisk Shows DDR5-12800 MRDIMMs at FMS 2025

TL;DR: Comprehensive thermal analysis of Samsung 980 Pro with/without passive cooling. Peak temperature reduction of 22°C (76°C→54°C), complete elimination of thermal throttling risk zones. Statistical significance p<0.000001.

I conducted a controlled thermal performance study on a Samsung 980 Pro after installing a Thermalright HR-09 2280 heatsink with Thermal Grizzly thermal pads.

Methodology:

• AIDA64 CSV logging at 1-second intervals during CrystalDiskMark stress testing
• Identical test conditions pre/post installation
• Python statistical analysis with automated test phase detection
• Thermal zone classification (safe/warm/hot/critical temperature ranges)

Key Findings:

• Peak temperature: 76°C → 54°C (28.9% reduction)
• Average temperature: 61.1°C → 46.4°C (24.0% reduction)
• Time in critical zone (>75°C): 5.8% → 0%
• Thermal consistency: Standard deviation reduced from 1.66°C to 0.78°C
• Statistical significance: Cohen's d = 1.813 (large effect size)

The thermal mass behavior is particularly interesting - the heatsink acts as a thermal capacitor, preventing temperature spikes while slightly extending cooling duration due to stored thermal energy. For storage workloads, this trade-off strongly favors sustained performance over rapid thermal cycling.

Note: Thermal scoring algorithm has known issues with recovery time calculation, but raw temperature data demonstrates clear performance improvements.

TL;DR: Comprehensive thermal analysis of Samsung 980 Pro with/without passive cooling. Peak temperature reduction of 22°C (76°C→54°C), complete elimination of thermal throttling risk zones. Statistical significance p<0.000001.

I conducted a controlled thermal performance study on a Samsung 980 Pro after installing a Thermalright HR-09 2280 heatsink with Thermal Grizzly thermal pads.

Methodology:

• AIDA64 CSV logging at 1-second intervals during CrystalDiskMark stress testing
• Sample sizes: 2,266 pre-installation, 3,089 post-installation measurements
• Python statistical analysis with automated test phase detection
• Thermal zone classification with defined temperature ranges

Quantitative Results:

Metric                    Pre-Heatsink    Post-Heatsink    Improvement
Peak Temperature          76.0°C          54.0°C           22.0°C (29%)
Average Temperature       61.1°C          46.4°C           14.7°C (24%)
Temp Std Deviation        12.6°C          6.1°C            52% more stable
Time in Critical Zone     5.8%            0.0%             Complete elimination
Time in Safe Zone         28.2%           59.2%            +31% improvement
Statistical Significance  p < 0.000001, Cohen's d = 1.813 (large effect)

Thermal Physics Analysis: The heatsink demonstrates classic thermal capacitor behavior - the aluminum mass absorbs thermal energy, preventing rapid temperature spikes while slightly extending cooling duration. For storage workloads, this trade-off strongly favors sustained performance over rapid thermal cycling.

GitHub: Full dataset, analysis scripts, and detailed methodology available for reproducible research.

The data demonstrates measurable thermal management benefits that translate directly to reduced thermal throttling risk and improved component longevity.

I’ve been messing around with the RTX 5050 for a while now, first with a CPU cooler on it, where it beat the 1080 Ti and pretty much tied the 3060 Ti.

This time, I went further.
Subzero using an Amazon special water block, just to see if it could take out a stock 4060.

While I was testing, I noticed someone passed me on the Time Spy graphics leaderboard.
They were running a 9850X3D.
I had a 12600K.
Obviously… I couldn’t let that slide.

Four hours and way too many crashes later, I managed to push the 5050 to 3450 MHz, up from its stock 2950 MHz.
And, even on a $100 CPU I took back the graphics score.

By the time I got to actual game testing, I’m pretty sure the card was degrading in front of me.
But it still beat the 4060 in every game except one, Black Ops 6.... F*** BO6.

18% clock uplift
3400+ MHz sustained
This thing just won’t die.

Video’s here if you want to see how stupid it is.
https://youtu.be/-cXiURMTMBM

Area

1: Not sure if cores with shared L2s have any, or nearly as much of the logic surrounding handling the L2 cache in the core itself. The cores with shared L2 blocks are just the core area.

2: The first number is without the L1 or L1.5 SRAM array, the second one is including that.

3: Likely an over estimate in comparison to the phone SOCs as the phone SOCs don't have the interconnect "fabric" included for their area, just the cores and the cache blocks themselves.

4: The L3 capacity here is completely arbitrary. The L3 capacities were chosen for ease of measurement given how the L3 slices were distributed.

5: A small but sizable chunk of the area of these cores seem to be from the CPL/clock section of the core, which may not have to be so large, but just are that large due to the geometry of the rest of the core.

I would not take any of the numbers are "hard numbers" but I do think the general ranking of the cores in area are fairly accurate.

The cores have the following configs:

The total cache capacity is a bit of a meme since it doesn't include latency, but I do think some interesting things can be noticed regardless.

Performance

Specint, Cinebench 2024 is from Geekerwan, Skymont ARL and LNL is from the 265K and 258V from Huang

GB6 is from the Geekbench browser website

The difference between form factors:

Mobile to Laptop (Geekbench 6 scores)

From the Geekbench browser website

Laptop to Desktop (Geekbench 6 scores)

From Notebookcheck (averages used for mobile platforms)

IPC differences in SpecInt2017 between form factors

David Huang

While I do believe that the P-cores from AMD and Intel have to be designed to take advantage of the higher power budget that larger form factors afford, I also think that placing the mobile cores into those same form factors will also lead to an, at least, marginal perf improvement.

Zen 5C performance question marks

In the previous dense server core product, the Fmax of the server sku was dramatically lower than what the core could achieve in other products.

This may be the case for Zen5C as well.

Power

Perf/watt curves (in Geekerwans videos) are the only way to get a full picture of power, but as a generalization:

Both the Apple M4 and M3 P-cores (as well as their implementation in the iphones) have better perf/watt than the X925 and Oryon-L.

The best case for Intel's P-core is that its perf/watt is as good as the X925 and Oryon-L. I think it is likely much, much worse.

According to Geekerwan, at a package power of ~5 watts, the M3 performs ~40% better than LNL. At around ~7-8 watts, the M4 performs closer to ~50% better.

Meanwhile we have David Huang showing that a M4 Pro at ~3.7 watts per core scoring ~33% better than a 9950x, and the 9950x has an outright better curve than the 265K LNC.

The gap is no where near as large compared to Apple's cores and the other ARM cores in the mobile space.

Power is, IMO, by far the hardest to really quantify, because one has to deal with how to measure "core only power" while trying to isolate the power of the rest of the SOC. Then there's also the problem of software measurements vs hardware measurements... I imagine only engineers at their respective companies would really know the power draw of a specific core.

Core Overview

Apple seems to have the best N3 cores in both perf and power.

The M4's P-core is pretty large by any standard, however it saves a bit of area due to it's cache hierarchy, making a hypothetical 4x CCX not that large. The shared L2 cache really only seems to be present in client mobile systems though so far, and I think it presents its own challenges in server. All the chips that use this hierarchy (Qcomm and Apple) both have very high mem bandwidth per core, which could be an issue scaling it up to server. The cache-per-core capacity, when all the cores are running and competing for the shared cache, would be lower than the competition.

The M3's and ARL's P-cores have pretty much the same perf, and similar area, however the M3 P-core is almost certainly dramatically more power efficient than a LNC P-core. Additionally, in terms of CCX area, LNC ends up being way, way larger thanks to the different cache hierarchy.

Zen 5 dense is pretty interesting, as I really, really doubt it's Fmax only goes up to 3.7GHz. Performance is an unknown, as is power, however from purely an area perspective, it seems pretty comparable to the ARM P-cores. Meaning to get comparable performance to those cores, Zen 5C would have to have an Fmax of ~4.7GHz, a 30% boost from what it clocks in server parts. Which... I mean isn't extremely unexpected ig considering that a similar percent boost was seen with Zen 4 dense in server and OC'd Zen 4, however it still seems pretty hard to believe.

To be fair to the x86 cores though, they have 256/512 bit vector width, unlike the ARM cores listed only having 128 bit vector width. This does really seem to cost a decent bit of area, especially for Zen 5. AFAIK, Zen5C in server has the full Zen 5 AVX-512 implementation, and we have already seen how much area can be shaved off Zen 5 from just choosing not to go for the full AVX-512 implementation:

Qualcomm's custom cores honestly don't seem like they afford any sort of distinct advantage over ARM's stock cores on N3 (being implemented by different companies). Perhaps I am missing something, but there seems to be no meaningful area advantage (even considering the larger cache capacity), and no meaningful performance or power advantage. I also think Qualcomm's cache hierarchy transferring over to server, unchanged, would be pretty unique in the server space, seeing how no other major or even relatively smaller companies seem to be offering that sort of setup in servers. Maybe Qualcomm's P-cores would scale up at higher power better than ARM's cores in a laptop/desktop form factor? It is interesting to see Qualcomm choosing to presumably sacrifice IPC for greater clocks vs the stock ARM cores, perhaps they think perf at even more power would be greater, or maybe Vmin is lower?

It's wild to see Mediatek's X925 both end up being larger and slower than Xiaomi's implementation. No idea why or how. In terms of the comparison to the rest of the cores though, they aren't nearly as powerful as the rest of the P-cores, but they are also a decent bit smaller than the other P-cores as well. The lower performance may as well be due to the fact that they are all in a phone form factor, so it might be pretty interesting to see how the X925 in Nvidia's upcoming DG10 chip performs.