Question Zen 6 Speculation Thread

[Kepler_L2]

Where are you getting this from? No longer just 2 MB L3 per core for Zen 6c, but 4 MB?? Thats news to me.

Yes that is correct

 

[adroc_thurston]

No longer just 2 MB L3 per core for Zen 6c, but 4 MB??

yeah you get a flat unified 128M L3$ slab for the dense CCD.
Full socket is like a whole gig-o-cache. snazzy.

 

[Joe NYC]

V$ is completely irrelevant for fmax SKUs.
It's completely irrelevant in server outside of specific HPC workloads.

I think that information is dated to Zen 3 / Zen 4 era, where you had fmax penalty to V-Cache. So the winning cases were only those where V-Cache could make up more than 300-400 MHz clock speed deficit.

In Zen 5, where boost and sustained clocks are much closer between V-Cache and non-V-Cache, V-Cache processors.

Overall, Phoronix showed 12% gain of V-Cache processors vs. non-V-Cache across server / workstation tests. Database tests, for example, showed big boosts in performance.

Now, that Intel is closed the gap a little bit with Xeon 6, I don't think AMD should extend the leads with Zen 6, so that Intel is, again, not competitive.

 

[adroc_thurston]

I think that information is dated to Zen 3 / Zen 4 era, where you had fmax penalty to V-Cache. So the winning cases were only those where V-Cache could make up more than 300-400 MHz clock speed deficit.

Oh I'm not talking about fmax penalties or anything.
V$ is just usable in a few niche workloads in DC and that's it.

Database tests, for example, showed big boosts in performance.

They're fixed tiny worksets, irrelevant to how real DBs work irl.

I don't think AMD should extend the leads with Zen 6, so that Intel is, again, not competitive.

venice-d inherently makes the lead bigger than ever.

 

[Joe NYC]

Oh I'm not talking about fmax penalties or anything.
V$ is just usable in a few niche workloads in DC and that's it.

Those were the old comparisons. They showed some workloads with big leads, some tied and some where V-Cache chip was behind.

But once you eliminate the clock speed penalty, all workloads move up. That's why 9800x3d is leading 9700x in phoronics tests by 11.9%

AMD Ryzen 7 9800X3D Linux Performance: Zen 5 With 3D V-Cache Review - Phoronix

www.phoronix.com

They're fixed tiny worksets, irrelevant to how real DBs work irl.

Database tests are a mixture of data that can fit and that cannot fit in the caches. More table you can fit into cache, the less bandwidth is consumed, and more processing can take place at speed of L3 latency.

venice-d inherently makes the lead bigger than ever.

For Oracle databases, you would probably want classic Zen 6, due to licensing costs.

And offering them with classic Zen 6 with V-Cache would move the performance a generation ahead. Something like Zen 7 performance out of Zen 6 processor.

We can assume that Zen 6 will already be quite well endowed as far as clock speeds, so the main thing holding it back will be memory latency.

 

[adroc_thurston]

That's why 9800x3d is leading 9700x in phoronics tests by 11.9%

12% perf bump on a part that's normally crippled by cIOD being Pretty Bad?
Whoa man serious stuff right here.

Database tests are a mixture of data that can fit and that cannot fit in the caches. More table you can fit into cache, the less bandwidth is consumed, and more processing can take place at speed of L3 latency.

The average perf bump will be tiny.

We can assume that Zen 6 will already be quite well endowed as far as clock speeds, so the main thing holding it back will be memory latency.

And offering them with classic Zen 6 with V-Cache would move the performance a generation ahead. Something like Zen 7 performance out of Zen 6 processor.

no, 10% skt perf bump is not "Florence-like performance".
Please get real and stop projecting nerd dreams onto products made for serious people.

 

[basix]

V-Cache in servers will probably get less relevant in the future:
- Z5 = 32 MByte per CCD
- Z6 classic = 48 MByte per CCD
- Z6c = 128 MByte per CCD
- Z7 = 7 MB/core are rumored, not clear if classic or dense. I would assume dense. Which would mean 224MB+ per CCD. Classic could stick to that or move to even more cache per core, because their cores are bigger

For some use case V-Cache will still bring a performance bump. Bit the margin should get thinner.

 

[adroc_thurston]

Bit the margin should get thinner.

Margin's already paper thin as it is.

 

[basix]

Some applications show >50% performance increase with V-Cache (some CFD solvers, RTL simulation, ...). I would not say that this is thin. But that will get thinner, the more cache per core and in total per CCD you have. Diminishing returns as usual.

V-Cache benefits are very application specific. For most use cases the gains are slim. So V-Cache SKUs are not a no-brainer. You need to know if it's worth for your use case.

 

[itsmydamnation]

I wonder if they would ever go memory side cache v-cache. those would/should get better hit rates on in memory DB's or systems using > then a CDD core allocation, obviously worse latency but you will still execute sooner then going all the way to slow ass server dram.

 

[basix]

You need very big amounts of such a memory side cache to get gains compared to a large L3$. Theoretically possible (e.g. stacking a large cache below the IOD), but not sure how big the gains will be.
I think it would make more sense to stack DRAM instead of SRAM on the IOD. Because of being stacked, you could reduce latency and increase bandwidth compared to regular DDR. It will be worse than SRAM in both regards, but feature much higher capacities (e.g. 16 GByte instead of 512 MByte). The result would be similar like what Intel did with their Xeon Max HBM integration, but without the high HBM costs.