I wanted him to answer the question as the claim was that the front end was not efficient because the SMT yield was greater.What do you mean by this? GF cancelled 7nm finfet.
SMT is symmetric. The front end and L1 has changed in Zen2, and it's much more capable despite only 4 decode/cycle. They almost doubled up op-cache.
https://www.anandtech.com/show/14525/amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome/8
They feed the L2 instruction code effectively using a new unit. Then have shrunk L1i (halved?) but doubled op-cache size.
The op cache can also now feed up to 8 ops per cycle versus the old 6 ops maximum; link above is new zen2 and this link is zen1 https://www.anandtech.com/show/1057...lers-micro-op-cache-memory-hierarchy-revealed
The decoder still chugs only 4. It may or may not bottleneck the performance. It just depends how the op cache is performing. They did a great job so I think it's likely rare that the 4-wide decode is an issue. Because Zen3 likely is mobile focused I think doubling up decoder might not happen unless there are energy efficiency tricks. (I remember Kaveri getting doubled up decode and I think it has a lot to do with why these little APU's made such good space heaters and why 8c Steamroller was cancelled.) Maybe they are designing a 6-wide decode.
This is total speculation and likely totally wrong; but it's my best guess.
I think they will widen the core a little more and do 4-way multithreading, so with four threads and wider core they may need to widen the decoder. I don't think it will be SMT4 though, but think they will add a "Threadrip" mode, that allows a pair of opportunistic threads to run on top of SMT2 and help keep the execution units busy. This would be similar to big-little in the acorn world. These small threads would run completely without speculation (taking turns pausing on branches) and out-of-order execution would be very limited.
For consumer enabling Threadrip would be a benefit; with quadcore APU having 8 strong threads, and 8 "small" threads. Building a kernel with -j16 would be a big speedup over a kernel build with only SMT2 enabled. Little threads would also have no vulnerability to spec execution. The OS can use it for itself and system processes. Browsers can be made to use it (eg offloading incessant and useless javascript threads associated with bg tabs). Little threads would be most useful for high latency and high FPU code and could be useful in parallel compute datacentres.
Zen3 would be primarily mobile focused, secondarily server focused; and hopefully the first to see this core would be a quadcore sub 10W APU, followed by 2 CCX chiplets for the server and consumer markets.
As far as product lines, I think unlike 3000 gen, consumer 4000 MCM's would be strictly single CPU chiplet APUs, with 8 CU Vega built into the IOX, and available for both Zen2 and Zen3 chiplets--Zen2 arriving late H1 and Zen2 in late H2 or early 2021.
I wanted him to answer the question as the claim was that the front end was not efficient because the SMT yield was greater.
statement I replied to:
"The SMT yield is higher, which means that the front end is still not efficiently feeding the execution units."
It's all in your head - you're looking for hidden agendas where there exist none.At least 4, the two i quoted an,d the two i linked, dunno for the rest but that s obscure benches set apart for 7 Zip and CB, i see no Spec, no Web Xprt (an Intel bench, but not "good enough for the purpose..), anything where AMD does well is removed and Blender/CB used as a cover..
What do you mean by this? GF cancelled 7nm finfet.
SMT is symmetric. The front end and L1 has changed in Zen2, and it's much more capable despite same old 4 decode/cycle. They almost doubled up op-cache.
https://www.anandtech.com/show/14525/amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome/8
They feed the L2 instruction code effectively using a new unit. Then have shrunk L1i (halved?) but doubled op-cache size.
The op cache can also now feed up to 8 ops per cycle versus the old 6 ops maximum; link above is new zen2 and this link is zen1 https://www.anandtech.com/show/1057...lers-micro-op-cache-memory-hierarchy-revealed
The decoder still chugs only 4. It may or may not bottleneck the performance. It just depends how the op cache is performing. They did a great job so I think it's likely rare that the 4-wide decode is an issue. Because Zen3 likely is mobile focused I think doubling up decoder might not happen unless there are energy efficiency tricks. (I remember Kaveri getting doubled up decode and I think it has a lot to do with why these little APU's made such good space heaters and why 8c Steamroller was cancelled.) Maybe they are designing a 6-wide decode.
This is total speculation and likely totally wrong; but it's my best guess.
I think they will widen the core a little more and do 4-way multithreading, so with four threads and wider core they may need to widen the decoder. I don't think it will be SMT4 though, but think they will add a "Threadrip" mode, that allows a pair of opportunistic threads to run on top of SMT2 and help keep the execution units busy. This would be similar to big-little in the acorn world. These small threads would run completely without speculation (taking turns pausing on branches) and out-of-order execution would be very limited.
For consumer enabling Threadrip would be a benefit; with quadcore APU having 8 strong threads, and 8 "small" threads. Building a kernel with -j16 would be a big speedup over a kernel build with only SMT2 enabled. Little threads would also have no vulnerability to spec execution. The OS can use it for itself and system processes. Browsers can be made to use it (eg offloading incessant and useless javascript threads associated with bg tabs). Little threads would be most useful for high latency and high FPU code and could be useful in parallel compute datacentres.
Zen3 would be primarily mobile focused, secondarily server focused; and hopefully the first to see this core would be a quadcore sub 10W APU, followed by 2 CCX chiplets for the server and consumer markets.
As far as product lines, I think unlike 3000 gen, consumer 4000/5000 MCM's would be strictly single CPU chiplet APUs, with 8 CU Vega built into the IOX, and available for both Zen2 and Zen3 chiplets--Zen2 arriving late this year and Zen2 5000 in late H2 or early 2021. Monolithic mobile quadcore Zen3 4000 APU arriving mid 2020 and mid H2 for AM4.
Let me start by saying I thought Zen was server first, everything else be damned? You stated multiple times that you expect Zen 3 to focus on mobile, and I disagree.
I'm surprised at what they did with the uop cache, doubled it?? Much larger than what Intel will have even with Sunny Cove. Cutting the L1i in half to help allow that seems like a great move.
I have to admit you lost me a couple times there. I may have to read this again in the morning when my brain is working again. I guess for know I'll say I agree on there being no SMT4. But then it looks like you say it will be wider and may need to widen the decoder. I was saying that and I thought you were just saying how Zen 2 does a much better job at decoding already? Not that I don't believe you, the 2x uop cache is surely helpful here.
Ian Cutress said:AMD is still using a hashed perceptron prefetch engine for L1 fetches, which is going to be as many fetches as possible, but the TAGE L2 branch predictor uses additional tagging to enable longer branch histories for better prediction pathways. This becomes more important for the L2 prefetches and beyond, with the hashed perceptron preferred for short prefetches in the L1 based on power.
[....]
One other major change is the L1 instruction cache. We noted that it is smaller for Zen 2: only 32 KB rather than 64 KB, however the associativity has doubled, from 4-way to 8-way. Given the way a cache works, these two effects ultimately don’t cancel each other out, however the 32 KB L1-I cache should be more power efficient, and experience higher utilization. The L1-I cache hasn’t just decreased in isolation – one of the benefits of reducing the size of the I-cache is that it has allowed AMD to double the size of the micro-op cache. These two structures are next to each other inside the core, and so even at 7nm we have an instance of space limitations causing a trade-off between structures within a core. AMD stated that this configuration, the smaller L1 with the larger micro-op cache, ended up being better in more of the scenarios it tested.
4-way SMT sounds silly. Has it ever been attempted before? Resource contention is going to be a huge issue as well as scheduling. Add worse energy efficiency as well.
Now Ice Lake (https://browser.geekbench.com/v4/cpu/13476154)
Integer score = 5410; Floating Point score = 5609; median frequency = 3825 MHz
Score/GHz Integer = 1414; Floating point = 1466
ICL vs Zen 2, ICL is 13.4 percent ahead in integer, 13.3 percent ahead in Floating Point.
Therefore Zen 3 needs to have at least 13% IPC improvement to catch up to Ice Lake in Geekbench, which is why I said 15% uplift is necessary.
I personally also don't think AMD will move away from CCX. Though the handling of L3$ is an area where we may see changes either way. There have to be more efficient ways in tapping into this ever increasing cache pool.Oh yes I know. I didn't word that well. What I meant was that the time already spent building on Zen 2, in addition to another 12-18 months, is not enough time to just nuke the CCX concept and do something else. Besides, it's working well for them, why mess with success? (Not directed at you, but whoever my original quote was responding to).
Sorry about that, I apparently messed up multiple quoting there (it was by turtile). Corrected the post.I'm not sure where that came from, but that quote is not attributable to me. I even clicked my handle and reread my original post to make sure I wasn't losing my mind.
That's not what that member said. He said that crypto, int and fp already benefit from faster memory. The memory score just skews the results, I believe I heard that even the author of the benchmark said that it will be separated from the overall score in future releases. Still, I do want to see more comparisons before claiming that Zen 3 needs a 15% IPC increase to match Sunny Cove. As for The Stilt's testing, I have my issues with his testing suite too. It's a bit vector heavy if you ask me.Frequency of Zen 2 in this test is 4.25Ghz, assuming ICL scale at 100% with frequency (wich would include bandwith and latency....) it would score 6253, wich is 6.4% better than Zen 2, dunno how you manage to reach 13.4%, sure that by selecting the relevant subscores that s not difficut.
As pointed by a member you cant remove latency and RAM bandwith that easily as this is used in GB computation of total performance and not including it will skew the result.
For instance the LZMA test in isolation can give very good numbers if the executed file is very small, but once you increase the size then this will be very sensitive in respect of these characteristics, best exemple is Zen 1 whose 7ZIP numbers were nowwhere close to the iNTEGER exe capabilty, in X264 where they matter less it did perform much better comparatively, in FP this is generaly not as sensitive.
There s the Spec comparison at AT wich show Zen 2 being faster than CFL, he tested at their rated frequencies and made a frequency normalisation, dunno if he accounted for the fact that his Ryzen set up wasnt boosting at the proper frequency with his first tests.
I personally also don't think AMD will move away from CCX. Though the handling of L3$ is an area where we may see changes either way. There have to be more efficient ways in tapping into this ever increasing cache pool.
Sorry about that, I apparently messed up multiple quoting there (it was by turtile). Corrected the post.
It might have been revived... with my rumor divison saying it has been stealth restarted.What do you mean by this? GF cancelled 7nm finfet.
It might have been revived... with my rumor divison saying it has been stealth restarted.
7nm FinFET is EUV(~175 wph) with e-beam inspection(slow-ish) with development restarting in 2019 to HVM planned for 2021.
3nm GAA is also EUV(>200 wph) but with actinic inspection(fast-ish) with development in 2022 to HVM planned for 2024.
What's happening, who's funding it, no answers as of yet.
I suspect you're not far ahead either. Using a benchmark with extremely high variance on memory speed and less than adequate ways of reporting memory speed, timings and clocks in general is a recipe for disaster for IPC comparisons.And as expected, you have no idea what to look for in Geekbench ST numbers.
The usual questions spring to mind:
- Will it support currently existing motherboards (300/400/500 series chipsets)?
- What kind of IPC increase are we talking about?
- Will AMD manage to squeeze more frequencies?
- What node will it use?
- What will be its TDP?
- Will it support AVX512 instructions?
- When and if we can expect Ryzen 4000 CPUs with modern onboard graphics (e.g. Navi10/Navi20)?
I see here that 7nm+ is supposed to give a 10% uplift in performance (I assume == clocks)
Assuming its not, maybe a 5% clock increase is possible?
So a 4.5GHz ceiling would become ~4.75GHz.
Here's another 9900K bench:
https://browser.geekbench.com/v4/cpu/13833746
Score/GHz Integer = 6810/5 = 1362
Well said.Energy efficiency of SMT is better than outright increasing resources. Extracting ILP generally needs square of the performance it brings, while for SMT its often better than linear.
4-way SMT has been done. The IBM Power series uses 8-way SMT. However, the IBM Power chips put significant effort into boosting SMT effectiveness, which won't be ideal on consumer chips. Sun's chips I think also used 4-way SMT.
On Intel/AMD chips, 2-way SMT adds <5% to core area(not total die). On Power 5, its SMT added 24% to core area. On top of that, going above 2-way SMT offers diminishing returns. 2-way SMT might offer 30% benefit. Doubling that again might offer 15%.
Difficulty of implementing SMT is also not about power or area, much as validation required to make things work. This is why the Merom core didn't have SMT, since the Haifa team had no experience. Nehalem brought back SMT because it was the same team that designed Netburst.
Software-wise, the application doesn't really know the difference between 8 core/16 threads and 16 core/16 threads. Performance also reflects this. Those that benefit from 16 cores benefit from 16 threads.
Well said.
A lot still don't acknowledge the area and power efficiency of SMT versus additional cores, up to a point of course. With 7nm+ only having a small increase in transistor density, the obvious way for AMD to aggressively increase thread count is to increase SMT values. A boon for some (a lot?) server loads.
I suspect you're not far ahead either. Using a benchmark with extremely high variance on memory speed and less than adequate ways of reporting memory speed, timings and clocks in general is a recipe for disaster for IPC comparisons.
Here's another 9900K bench:
https://browser.geekbench.com/v4/cpu/13833746
Score/GHz Integer = 6810/5 = 1362
Suddenly Ice Lake is just 4% faster and all AMD needs to do is a Zen 2 refresh similar to Zen+.
Just because Geekbench scores are all we have on Ice Lake doesn't mean we should use these scores to evaluate IPC gains. I can come up with R7 2700X scores vs. R7 2700 scores that indicate Zen+ is 5% faster than... Zen+ in ST integer.
I'm not looking at individual subtest scores, just the overall integer and floating point scores. How I got 13.4 percent is elaborated in my post. It's not my problem that you fail to grasp the method.Frequency of Zen 2 in this test is 4.25Ghz, assuming ICL scale at 100% with frequency (wich would include bandwith and latency....) it would score 6253, wich is 6.4% better than Zen 2, dunno how you manage to reach 13.4%, sure that by selecting the relevant subscores that s not dif
I don't see how that would work. The front end is probably pushed to its max during full load (both threads active). If the SMT yield is higher it kind of points to the front end doing its job. However, there isn't a way of knowning; perhaps if the the front end were improved, the SMT yield would rise even further. Basically, I don't think there's any info, and that statement doesn't make sense.
But it does seem plausible the 4-wide decoder could be holding back performance. (The likelihood also increases if AMD goes beyond SMT2.)
It seems the improved SMT yield is probably mostly from the wider core (up to 3 loads per cycle now).
Now the big question is, where will they widen the core next (assuming it's widened in Zen3).
It could very well be that the width remains the same (4+3).
Would increasing the maximum writes/stores per cycle from 1 to 2 cause a lot of issues or complexity?
I'm not looking at individual subtest scores, just the overall integer and floating point scores. How I got 13.4 percent is elaborated in my post. It's not my problem that you fail to grasp the method.