noI wanna know the clustered decode of zen 5 is still useful without SMT?
I wanna know the clustered decode of zen 5 is still useful without SMT?
Mike Clark talked about that in the Chips and Cheese interviewI wanna know the clustered decode of zen 5 is still useful without SMT?
No, IPC will go up, the same way you posting the same question in two forum threads at the same time has increased your actions per minute by a considerable amount.When every thread has been used ,every thread use just 1*4 decoder,the IPC should decline?
Look at this. A whole 2% gain for fetch and branch prediction. This is how CPU designs are.Some rough math (normalized to 16% IPC gain):
View attachment 103113
I interpreted that as meaning you still have fetch ---> decode, which is in-order, but there's two parallel paths now instead of one, meaning you have a dual-ported instruction fetch feeding into dual decoders. I also interpreted Mike's following statements about each decoder knowing where to start as meaning both decoders can work on the same instruction stream.At 2:10 in the CnC's video Mr. Clark clearly states they still do decoding in-order. What does that mean in context of Tremont+ style of fetch & decode?
I again want to know why David Huang's results showed zero parallelism from the two clusters in ST. Is it disabled in mobile or does it only work situationally?I interpreted that as meaning you still have fetch ---> decode, which is in-order, but there's two parallel paths now instead of one, meaning you have a dual-ported instruction fetch feeding into dual decoders. I also interpreted Mike's following statements about each decoder knowing where to start as meaning both decoders can work on the same instruction stream.
I would exercise patience in this situation tbh. Huang's article was based on an ES with a non-final microcode and he himself admitted to having been time-constrained. Let's wait until C&C get their hands on the thing.I again want to know why David Huang's results showed zero parallelism from the two clusters in ST. Is it disabled in mobile or does it only work situationally?
Except you have a 6k uop cache, so even if that is the case , i listed to that section 3 times and cant find anything as definitive as you claim your claim of ILP, it wont hold true at dispatch.for those wondering, it sounds like from the interview, that zen 5 is 8 wide decode, but can only decode from one branch path of a single thread at a time per that decode unit. so real world gains would still be only around the previous zen 4 offerings of 4x ILP.
uop cache gets around decoding, but hits in the cache only apply to small loops, so i would argue its not really sustained perf here.Except you have a 6k uop cache, so even if that is the case , i listed to that section 3 times and cant find anything as definitive as you claim your claim of ILP, it wont hold true at dispatch.
would they not be storing highly likely taken branches uops in the op cache. So when you look over time your decode a cycle a thread is higher . Mike said they can "look ahead" for branches.uop cache gets around decoding, but hits in the cache only apply to small loops, so i would argue its not really sustained perf here.
Going from 1x9 throughput uopcache to 2x6 throughput uopcache is also an SMT minded decision, because with ST, it would be a downgrade.
For what we’re launching today in Strix Point, both the performance core and the compact core both have the AVX cut-down [AVX-256] because they're in a heterogeneous situation, and they're in a mobile platform where area is at a premium.
Heh, my bad.Some Zen5/Zen5c uarch details have been revealed: https://www.phoronix.com/review/amd-zen-5-core
Edit: I somehow missed @Saylick post, sorry.