You can find it in the microbenchmarks from Chips and CheeseSorry, could you explain how you came to that conclusion?
Each Zen 5 cluster only handles a single thread, and maximum frontend throughput can only be achieved if both SMT threads are loaded. Intel’s scheme has all clusters working in parallel on different parts of a single thread’s instruction stream.
In this test, a single Zen 5 thread still performs like a 4-decode x86 core. But when we enable two SMT threads for testing, we can see that the throughput doubles, and the instruction throughput reaches 8 in the L1-L2 and even L3 ranges, and in the DRAM range it returns to the same normal level as Zen 4.
Huang performed his tests on the Zenbook, whereas C&C did theirs on the PX13. No GNR tests yet.Have these analyses of the apparent decoder width in 1T vs. 2T been done only on Strix Point so far, or did anybody reproduce them on Granite Ridge already?
Plus, Strix Point tests = Asus Zenbook tests, on which there is no BIOS option to disable SMT, or is there?
(I'm afraid I lost track.)
You should probably also include the funniest bit:
Personally, I think VP2INTERSECT is a disgusting instruction...
the instruction probably should never have existed in the first place in its current form. This may be one of the reasons Intel decided to get rid of it. It's unclear exactly what the original task was that it was meant for.
Skymont clocks noticeably higher. Arrowlake's P core had to downgrade by 5%, but the E core clock went up by 200MHz. It goes up to 4.6GHz on Arrowlake.Edit: once all the figures are on Skymont is still a huge leap in efficiency and PPA for Intel but not quite class leading. The irony is that in servers both Skymont and Zen 4c/5c are both going for the one market where ARM does really well.
Do we know the clock rates of N3E Zen 5C?Skymont clocks noticeably higher. Arrowlake's P core had to downgrade by 5%, but the E core clock went up by 200MHz. It goes up to 4.6GHz on Arrowlake.
Maybe Intel just don't like to be embarrassed though?
It would not matter so much for Turin D, I suspect it will be an efficiency play, so lets say 192 Cores at 2.8G@360W, up from 128C 2.25G@360W would already be a big perf uplift, no need for 3.5G+ clocks. Power per core would really be the most interesting part in my view.Do we know the clock rates of N3E Zen 5C?
Yes, that seems possible. But I think this is lower power per core than what it was being compared to (253W for 24 cores)It would not matter so much for Turin D, I suspect it will be an efficiency play, so lets say 192 Cores at 2.8G@360W, up from 128C 2.25G@360W would be a big perf uplift. Power per core would really be the most interesting part in my view.
Overall, despite the suspected shrinkage of op cache equivalent capacity in previous tests, Zen 5 maintains fairly high op cache utilization in most cases. That is, for SPEC int, the width of its x86 decoding is in most cases harmless to the overall performance, as will be seen later in the performance analysis. (DeepL)
By looking at the PMCs associated with the mop source, we can see that even though the mop cache of Zen 5 has shrunk from 6.75K to 6K, the actual efficiency has increased. In the vast majority of cases, the percentage of mop from x86 decoders is smaller for Zen 5 than for Zen 4.
Op cache gives a performance boost of around 23% for the Zen 5. As a comparison (non-rigorous), based on readily available test data, the 7950X with op cache turned on has a performance gain of only about 13%. As you can see, op cache is far more important for Zen 5 than for previous generation architectures.
x264 subcomponent: significantly higher bottlenecks in the back-end execution unit, access memory, and some bandwidth bottleneck increase in the front-end. In the end, the two new dispatch slots added by Zen5 only improve retire/ipc by 0.4;
This is very easy to understand. x264 has a very large number of compiler-generated SIMD integer and SIMD-access instructions, whereas the mobile Zen 5 has a significant regression in this area (SIMD integer latency and throughput drop) or no significant improvement (SIMD access, especially 128/256bit)
To be honest I just want to understand how it works, that is why I hope somebody will check uOP caches are probably doing wonders for well written math kernels but when it comes to branchy workloads [hello games] they can only do so much.Maybe people are focusing too much on the dual decode not being active for 1T. Dual-feeding is still possible from uOP cache and that may be bigger factor than decode capacity itself.
While I would generally agree, for the comparison David did Zen 4 and Zen 5 were running the same code, therefore x264 could be the one place where the 1c increased latency of SIMD instructions could be hampering other places. SIMD int add for example was 1c latency on Zen4 its 2c on Zen5. Instruction breakdown of x264 would be nice to see, to check if the adds could really have this influence.That is probably artifact of the SPEC code only using autovectorization and disabling all hand-written ASM code that is large part of x264. That assembly does a lot of work in tightly tuned SIMD routines that pack as much work as possible into as little cycles as possible.
When you disable assembly code, you will force the compiler to recreate all that from C code by autovectorization, and autovectorization is notorious for not working that well with complicated multimedia code that is not straightforward numerical HPC code. So basically the autovectorized code generates massive number of extra adds, muls, shuffles, probably heavily shifting the balance of the execution characteristics. I suspect that x264 compiled properly would show lesser level of backend bottleneck even on the modest 256bit mobile Zen 5 core, although software video encoding of this quality is still extremely computationally intensive, so it may be more backend-bottlenecked than other code.
Good, now it got a 11% IPC gain. Still a long way to the marketing's 16% figure.Well looks the issue is now solved. David updated the results. Zen 5 is ahead of Zen4 in x264.
This is integer rate. IPC would include some weighting of fp rate, right?Good, now it got a 11% IPC gain. Still a long way to the marketing's 16% figure.
It's a more like a tounge-in-cheek post.This is integer rate. IPC would include some weighting of fp rate, right?
I guess you can argue it too is misleading because, in the past, AMD typically matched what their slide said to the SPEC int rate and this time they didn't. But it's not like the gaming slides. Still a bad regression in marketing accuracy.
Good, now it got a 11% IPC gain. Still a long way to the marketing's 16% figure.
I find this argumentation weird. Besides the thing that calling it differently doesn't change any real behavior or merit of the core... how exactly do you determine if it uses the same philosophy as Zen 1-4? On what is that based?(... ) Zen 5 does not follow the same philosophy as its Zen predecessors. (...)
Again, Zen 5 should not be presented as a successor to Zen 1-4 but something of a different lineage. Then we would likely not see these oddities.
It is based largely on the decisions made by the architects. There is no silver bullet so these decisions are basically trade-offs.I find this argumentation weird. Besides the thing that calling it differently doesn't change any real behavior or merit of the core... how exactly do you determine if it uses the same philosophy as Zen 1-4? On what is that based?
Well looks the issue is now solved. David updated the results. Zen 5 is ahead of Zen4 in x264.
It has these regressions in 256b version too. I don't think the regression is the result of the vector register width but some other change.On top of that it lead to regressions for various instructions.
Not sure where the table comes from, but it doesn't seem to show branch misprediction rate. Even when you have few branches, they can be hard to predict.According to this paper, both tests are on the lower end in terms of how branchy the code is. Not sure why it’s performing relatively less in them though.
View attachment 105230
Not sure where the table comes from, but it doesn't seem to show branch misprediction rate. Even when you have few branches, they can be hard to predict.
Leela and deepsjeng are running through game trees making decisions depending on evaluation functions. That's very data dependant and branch predictors can have a hard time with that.
Several benchmarks (e.g., leela r, mc f r, xz r) spend a significant fraction of their execution time on front-end stalls as they suffer from higher branch misprediction rates