- 3 64 bits integer multipliers up from 1; that’s strange, these instructions rarely are a bottleneck (except outside of things like GMP, RSA); if this is confirmed, Zen5 might prove great for computational number theory.
There are some other applications in bitboard based game engines (though in these engines integer SIMD often is the way to go) and a low latency imul will always be faster than some integer lower cost operations.I don't get it either. (I also don't get why ARM went from 2 to 4 imul's in X925.)
Profiling has shown over and over again that the vast majority of multiplies executed are by constants, which shouldn't be lowered to imul anyway. Relatively few of the ones that aren't by constants are perf-critical unless you're doing, like, integer digital signal processing.
- 3 64 bits integer multipliers up from 1; that’s strange, these instructions rarely are a bottleneck (except outside of things like GMP, RSA); if this is confirmed, Zen5 might prove great for computational number theory.
I don't get it either. (I also don't get why ARM went from 2 to 4 imul's in X925.)
This is absolutely not justified on the basis of common loads using that many parallel scalar muls. My best hypothesis is that it's about scheduling, the logic to pick an execution unit takes way more transistors than the execution units themselves, AMD has in the past had superfluous execution units to simplify scheduling. For example, K7 and K8 had more AGU units than could be served by the memory pipes, because this allowed them to treat the three "pipes" as identical in the scheduling logic.
This is absolutely not justified on the basis of common loads using that many parallel scalar muls. My best hypothesis is that it's about scheduling, the logic to pick an execution unit takes way more transistors than the execution units themselves, AMD has in the past had superfluous execution units to simplify scheduling. For example, K7 and K8 had more AGU units than could be served by the memory pipes, because this allowed them to treat the three "pipes" as identical in the scheduling logic.
I hope some of these folks who do microbenches (like David or Cheese) put up a new article once 9000 series are available.I guess, this is what Mike Clark was so excited about already several years ago. Zen5 was not meant as one single generation to rule them all, but might be seen as a foundation for the coming years that might reap the benefits when process technology allows them to better use that new front-end. IMHO it is quite possible, they had to scale Zen5 back a bit due to N3 not being financially feasible.
The only exception observed in the chart is the test with one branch per 64 bytes, where the latency spiked after exceeding 16384 branches. After calculation, it is easy to find that 16384 * 64B = 1 MB, which means that the code footprint has exceeded the L2 capacity when the latency increases.
IMHO feeding the beast (e.g. the cache hierarchy, etc) is a much bigger bottleneck. It's not like they didn't widen the backend (though there definitely is more room looking how Zen 1 -> 4 evolved)My humble observation: Combined with what AMD has publicly stated about Zen5's core, the front end was widened in preparation for future back end work. They probably ran out of area budget to add more on the back end given the process node they are using. I suspect that we'll see the back end get more fleshed out with Zen6 on N3 family nodes, though, it won't be as pronounced as some are expecting.
Translated:Updated SIR 2017 results for STX by David Huang.
I dislike laptop benchmarking, especially when trying to figure out uarch differences.Translated:
“Updated Ryzen AI 9 HX 370 (the name is really hard to pronounce) big/small core test results. The big core can touch the level of M2, and the small core is at the level of 8cx gen 3 big core. The cache capacity of these two groups is similar, but ARM has some SLC
Where do you see the opposite? Zen5 mobile core scores 9.72, Zen5c mobile core scores 6.45?I dislike laptop benchmarking, especially when trying to figure out uarch differences.
Why does Huang get such a different result from Geekerwan? Geekerwan tests showed the AMD E core noticeably slower than their P core, and Huang shows the opposite. This isn't the first time.
This is why it needs to be released and the tests done properly on a DESKTOP platform. Anandte....(sorry didn't meant to beat a dead horse) HWUnboxed, TechPowerup, GamersNexus, Computerbase, etc.
Where do you see the opposite? Zen5 mobile core scores 9.72, Zen5c mobile core scores 6.45?
In-depth core analysis from Y-Cruncher author (Alexander J. Yee) http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/
It is possible AVX512 might matter soon enough.From the developer standpoint, what this means is that there quite literally is no penalty for using AVX512 on Zen5. So every precaution and recommendation against AVX512 that has been built up over the years on Intel should be completely reversed on Zen5 (as well as Zen4). Do not hold back on AVX512. Go ahead and use that 512-bit memcpy() in otherwise scalar code. Welcome to AMD's world.
Looks like a heavy memory bottleneck issue as found by David as well.In-depth core analysis from Y-Cruncher author (Alexander J. Yee) http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/
1 MiB of L2 is so not cheap in terms of area, though.Looks like a heavy memory bottleneck issue as found by David as well.
Similarly, the regression in 1cycle SIMD instructions also noticed by David. But seems this is a new hazard that could be resolved not some major architectural limitation in future uarchs
Heavy focus on AVX512 while no focus made to 128 bit and 256 bit instructions.
Likely that another 1MiB of L2 would have helped to get some extra perf, it is not an overly thirsty chip. But the fabric really needs an overhaul.
Unfortunately, it's unlikely as most of the market is AVX2 and Intel will try to push AVX10/256 as much as possible because of their E-cores so unless AMD manages quickly to grab a lot of marketshare I don't expect current status quo to change in any meaningful way.It is possible AVX512 might matter soon enough.
Improving that [doubling execution units] would require much greater silicon expenditure, because they would need to double the amount of ports from register file [it seems that they believe 10 is the optimum under current constraints as they stick with it in Zen4, Zen5, not sure about Zen3]. Generally from core point of view wider vectors are better than more smaller ones as you need to decode less instructions [doesn't matter so much for ARM where instruction length is fixed] to do the same amount of work. But it's harder to code for, and thanks to AVX512 fragmentation no consumer HW, except for Zen4/5 and Intel 11th Gen has it what makes TAM rather small.Heavy focus on AVX512 while no focus made to 128 bit and 256 bit instructions.
The latency has increased for SIMD instructions from 1 to 2 cycles. Because of this SSE instructions seems to suffer. So any workload using this instructions might see a slight regression from Zen4.In-depth core analysis from Y-Cruncher author (Alexander J. Yee) http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/