Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Test Results for AMD Zen 5

agner.org

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Test Results for AMD Zen 5

#61

Post by alberth »

ksec wrote: post #54

Given how Apple's M4 Core can access all of the L2 Cache ( it is shared ) and has a SLC ( System Level Cache ) one could argue it is better to compare it to AMD X3D variant on Cache size. However on Geekbench 6 it is still off by 30-40% per clock. Even if we consider zero performance improvement from M5, it would be a large jump for Zen 6 to catch up. And that is also the case with Qualcomm's Oryon and ARM's own Cort…

Isn’t Zen fab’ed on nodes sizes Apple used 2-3 years ago (since Apple pays for exclusive rights to TSMC for latest & greatest node sizes).

Re: Test Results for AMD Zen 5

#62

Post by menaerus »

Sesse__ wrote: post #45
monster_truck wrote: post #33

This matches my experience with Zen in basically any generation. Once you've used all of the tricks and exhausted all of the memory and storage bandwidth, you'll still have compute left. It's often faster to use one less core than you hit constraints at so that the processor can juggle them between cores to balance the thermal load as opposed to trying to keep it completely saturated.

I had real code that ran with IPC > 6 on Zen 3; I think that's the first time I've seen a modern CPU _really_ be ALU-bound. :-) But it was very unusual, and when I vectorized it, it ran completely different.

Zen3 decode is 4-wide + 8 uOp cache, and dispatch backend is 6 uOps wide. Theoretically, it shouldn't be possible to have IPC larger than 6.

Re: Test Results for AMD Zen 5

#63

Post by mmis1000 »

menaerus wrote: post #48
crest wrote: post #29

Earlier quoted context omitted.

Depends on your usecase. For a thin 14" laptop an M4 is probably the closer sweet spot, but for CPU heavy workloads Apple doesn't offer anything comparable to Threadripper or EPYC (lots of fast cores, enough memory and I/O bandwidth).

Actually Apple M design can hit ~100GB/s of MBW with a single core. Something that many other (or basically none?) CPUs of the same range couldn't.

Maybe wait for the next release of amd mobile cpu? I heard that they throw 384 bit bus on i-gpu. While the main purpose is for faster vram access. It surely will also benefit memory bound cpu tasks.

Re: Test Results for AMD Zen 5

#64

Post by menaerus »

mmis1000 wrote: post #63
menaerus wrote: post #48

Earlier quoted context omitted.

Actually Apple M design can hit ~100GB/s of MBW with a single core. Something that many other (or basically none?) CPUs of the same range couldn't.

Maybe wait for the next release of amd mobile cpu? I heard that they throw 384 bit bus on i-gpu. While the main purpose is for faster vram access. It surely will also benefit memory bound cpu tasks.

Server CPUs are hitting those numbers already for many years, including the AMD. The thing here is that Apple optimized their core for a different workload than the rest. I don't think there's a secret sauce AMD isn't aware of given their other line of CPUs - they know how to achieve it.

In multi-threaded scenarios, for example, M chips are not better at all and AFAICR are worse than the Threadripper. So, a different trade-off really

Re: Test Results for AMD Zen 5

#65

Post by Sesse__ »

menaerus wrote: post #62
Sesse__ wrote: post #45

Earlier quoted context omitted.

I had real code that ran with IPC > 6 on Zen 3; I think that's the first time I've seen a modern CPU _really_ be ALU-bound. :-) But it was very unusual, and when I vectorized it, it ran completely different.

Zen3 decode is 4-wide + 8 uOp cache, and dispatch backend is 6 uOps wide. Theoretically, it shouldn't be possible to have IPC larger than 6.

I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.

Re: Test Results for AMD Zen 5

#66

Post by Sesse__ »

kvemkon wrote: post #59

> AMD chips don't have an equivalent to Intel PT. We'd love to add support as soon as they make one. (2022) [1] > since 2013, Intel offers a feature called "intel processor tracing [2] > [not answered] > When will AMD cpus introduce Intel-PT tech or the Intel branch trace store feature? (2024) [3] > [not answered] Is Intel-PT over-engineered and not really needed in practice? [1] https://github.com/janestreet/magic-t…

I've used Intel PT several times; it's completely unbeatable for some things.

In general, Intel is _way_ ahead of AMD in the performance monitoring game. For instance, IBS is a really poor replacement for PEBS (it still hits the wrong instructions, it just re-weights them and this rarely goes well), which makes profiling anything branchy or memory-bound really hard. This is the only real reason why I prefer to buy Intel CPUs still myself (although I understand this is a niche use case!).

Re: Test Results for AMD Zen 5

#67

Post by menaerus »

Sesse__ wrote: post #65
menaerus wrote: post #62

Earlier quoted context omitted.

Zen3 decode is 4-wide + 8 uOp cache, and dispatch backend is 6 uOps wide. Theoretically, it shouldn't be possible to have IPC larger than 6.

I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.

It's interesting nonetheless. I wouldn't expect measuring such an IPC in the wild without having to craft the code in such an artificial way so that it hits that bound.

Re: Test Results for AMD Zen 5

#68

Post by Sesse__ »

menaerus wrote: post #67
Sesse__ wrote: post #65

Earlier quoted context omitted.

I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.

It's interesting nonetheless. I wouldn't expect measuring such an IPC in the wild without having to craft the code in such an artificial way so that it hits that bound.

Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports.

Perhaps instruction fusion somehow played into it?

Re: Test Results for AMD Zen 5

#69

Post by ksec »

alberth wrote: post #61
ksec wrote: post #54

Given how Apple's M4 Core can access all of the L2 Cache ( it is shared ) and has a SLC ( System Level Cache ) one could argue it is better to compare it to AMD X3D variant on Cache size. However on Geekbench 6 it is still off by 30-40% per clock. Even if we consider zero performance improvement from M5, it would be a large jump for Zen 6 to catch up. And that is also the case with Qualcomm's Oryon and ARM's own Cort…

Isn’t Zen fab’ed on nodes sizes Apple used 2-3 years ago (since Apple pays for exclusive rights to TSMC for latest & greatest node sizes).

Yes. N4 or 5nm Class compared to Apple's N3E or 2nd Gen 3nm. But the gap in IPC remains the same regardless of node. AMD could scale higher or has lower energy usage, it still wouldn't change the performance.

Not only is the Zen 5 slower, it also uses more energy to achieve the its results. Thinking about that the gap is staggering.

Re: Test Results for AMD Zen 5

#70

Post by menaerus »

Sesse__ wrote: post #68
menaerus wrote: post #67

Earlier quoted context omitted.

It's interesting nonetheless. I wouldn't expect measuring such an IPC in the wild without having to craft the code in such an artificial way so that it hits that bound.

Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports. Perhaps instruction fusion somehow played into it?

Probably everything that there is including the instruction fusion, no decoding aka uop cache, ideal port dispatching, no data dependency etc. If it was a loop then perhaps even LSD.
Post reply on HN