5min of stupid amd marketing and awkward head engineer reaction to the right question "why its just 16%" after 2 years of "progress". he knows amd gutted 9000 to make discounted 7000 look better in comparison. no more clocks, no more transistors, no more cores, no 3d-vcache. amd literally GUTTED zen5 to not compete much because intel/qualcomm aren't competing at all too. so amd does intel now. 14nm+++++++++ 12-14 "gen" with minimal uplift now from amd.
I love his attitude. Sometimes it's the "weird" questions that trigger the nugget, because in order to give the answer to it, you might have to explain it differently than the last ten times you've answered questions that are similar but not identical. And then you go "wait, why DID we do it this way?" And it's not always ground breaking questions. Sometimes it's just questions that challenge the "that's how it's always been". Best example I know of isn't mine - it's an anecdote I heard from a teacher, and the grumpy face he put up as he told the story just showed how angry he was that HE hadn't asked the question. He worked in a machine shop, and he was showing two 9th or 10th grade classes around the various shop buildings they had. They walk into one production hall, and as they walk in he gestures towards a very large water bath and says "be attentive, because otherwise you'll" and is interrupted by a loud thump followed by angry swearing, as one of the teachers had banged their shins into a drain valve at the end of the water bath. "Don't feel too bad about it - the rest of us do that once or twice a year as well, and I've worked here for more than ten years." Then one of the students raised a hand and was told to ask their question. "Why don't you just move the valve to the underside of the bath, so you don't bang your shins against it?" And it's now 30 years on, and I can still see my teachers angry, contorted face as he paused while telling the anecdote. The valve was moved at the end of the work day, with the boss himself doing the work. Apparently the boss had ended up in the ER due to the valve at one point, so it was revenge I guess.
Just like to say I have always been a very happy AMD system customer, and that has to be down to people like Mr Clark who have shaped the company and encourage this very positive, engineering-focused attitude. I can honestly say I've had nothing but good experiences - and I've always built my own systems. (I'm an electronics engineer by trade.)
So very application specific and will benefit more applications under development. Applications with rich customers, your world spins faster. Kudos to AMD.
I grew up, so to speak, on P2/P2 & quickly dabbled in K6-2 350 to K6-3 500 before going back to a I5- 3750k (great CPU) that lasted till Zen Ryzen1600X on a AX370 K7, which is still running well with a 3600X today. Only just purchased a 7600x, Tomahawk & FlareX again, another Samsung, 990 Pro. Yet to be installed. The only regret I have is not spending the $6000 spare I had on AMD shares at the beginning of Zen. I always like an underdog, they put that extra effort in & are often willing to take a chance on change. O well, at least Zen got me out of the upgrade silly-cycle. They have provided reliable service for years.
@@MissMan666 amd just REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to this techtechpotato Mike Clark interview :/. thats it. then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd AMD is doing intel now
@@MissMan666 AMD is doing intel now. they REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to this interview. then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd
@@cemsengul16 that's more because of the focus and bad management decisions AMD was also in the hole in 2015... before Lisa came. And Mike Clark was there also and still AMD had the buldozer fail. So it's more about the targets and the team and not because a company lacks talent
no its not, amd just REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to techtechpotato Mike Clark interview :/. thats it. then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd AMD is doing intel now
9000 only exists to make discounted 7000 look better, 7000 which almost nobody bought because there's no faster affordable GPUs to make a difference with 5000 ryzen. now they hope to sell through 7000 because 9000 makes 0 sense.
and there's no faster affordable GPUs because main amd business is selling cheap to make obsolete chips for consoles to sony/ms which is also not interested in progress with PC GPUs because consoles. progress with PC GPUs would make 2016-level hardware in consoles look VERY BAD in comparison. so amd nerfed their PC GPUs too e.g. halved Infinity Cache and set unreasonable prices because feature set isn't even close for how overpriced it is.
all what ayyymd has to do is just connect SSD to a GPU chip directly (like they already do with obsolete chips in consoles and did on their PRO SSG card in 2016) and PC GPUs can get TERABYTES of 'VRAM' like 2-8TB i.e. WAY BETTER DirectStorage without long PCIe bus lag/latency => way better textures/models = movie-like graphics. but 1) its the endgame GPU, the last GPU you will EVER need to buy, so nobody wants to actually make it and sell it 2) it will kill consoles and GaaS businesses for amd, nv, ms, sony. thats why corporations are just milking the market with obsolete cheap-to-make overpriced 3-4 times hardware - they've got too close to the end of progress with what they sell. + selling the same old tech year after year without spending much on R&D is way more money than making actual progress = prices on old tech don't drop.
Interesting point about software needing to catch up to the hardware! I wonder if AMD will try to contribute enhancements to compilers to take advantage of this stuff... it might be difficult because you'd have to justify giving up performance on older, slower chips in order to make the newest chips faster. Well, either that or ship another variant of the logic that only runs on the latest chips - might be justifiable for some applications but probably a hard sell for most.
Depends. AMD have already proven they will be anti-consumer when they want - they 100% destroyed their entire enthusiast userbase with a deliberate bait and switch for their previous Threadripper non-pro platform, TRX40, by EOL'ing it not long after it was released - despite that now infamous "long term support promise". My own belief is that AMD will bring out a new socket for Zen 7, incompatible with earlier CPU's.
That sounds overly optimistic, not just a bit. Not only in the number of generations (4 instead of 3 on AM4) but also in terms of years. Zen 3 launched 3 years after Zen 1. But Zen 7 will come in 2026 ? 2027 ? Which is 4 - 5 years after Zen 4 (2022). That's A LOT more, because you'll have to support it at least 1 extra year after the initial launch, as it's basically guaranteed that not all CPUs and APUs will be launched at once. And the board parteners, ASUS, Gigabyte, MSI and the rest, they won't welcome that. It will be a tremendous pressure on the early cheap motherboards to be made to be compatible with the extra generation, a big problem since those boards have really low profit margins, so 1 year of extra support of BIOS revisions is going to eat this into the negatives. If you think about it, other than being a very nice thing for us, the consumers, it is really stretching it way more than it is designed for and that the industry is prepared for. Something like this has to be planned before, and they barely confirmed... if I'm not mistaken, the Zen 6 support.
@@erkinalp Uhh no. Mike Clark created Zen 2 chiplets, which has made AMD $100+ billion in market cap and a bright future. NVidia has someone or some group of designers that has been kicking-ass in GPU design for years now, and wiping the floor with AMD GPU design. Who is this person/people?
That you got a patent for something does not mean it is feasible already or that other limitation/problem need to be solved first and that can take years.
15% is the target and Minimum Viable Product is an approach that all but guarantees gas in the tank for the next architecture while after getting the 15% lets you target bringing down costs to manufacture and heat to again make that 15% next year without hiccup. 15% is what is needed as the x3d will be out by lunar lake and likely AMD could win a price war v.s. lunar even if Intel has a Minimum Awesome Product moment. I'd also like to say once you hit the 15% you can focus on stability in all apps and software two small things with huge impact so nice AMD.
This is one if the downsides of a chiplet architecture as you need more pJ/bit when you need to move the data out of the die through the organic package interconnect and back. That is why for the mobile SKUs they are monolithic as idle power is much more important. Using an silizium interposer or bridge like EMIB would help but also increases cost and lowers yield.
@@egalanos no, over the zen4 it is probably why we see the small ipc uplift, because it is held back by the io. the mobile parts are cutdown cache wise so the perf is very gimped, so no. if zen4 had an monolithic sku with 32MB of level 3 cache and the better IF we would see better perf over what zen4 have. If zen5 was monolithic with all the improvments it has over zen4 it would be even better that what we get now with zen5. but in some aplications, ie many synthetic tests the test run pretty much from the cache so the need for better imc would not be there.
@@frankstollar8492 ipc is not a number fixed in stone. It changes depending on the application. It simply means how much work it does or additional perf it has over the sku compared to it. U-code, application improvements for the u arch, and even cache and ram frequency might improve the ipc. For instance ipc of 7800x3d in games is highest because the cores don't need to wait for ram and can execute much faster and u get higher perf.
@@TechTechPotato You should watch the C&C video nevertheless, multiple times, because you clearly don't understand the difference between your approach to making tech videos and C&C's approach to making tech videos. The question you asked "Why is it only 16% IPC" is a question that a 15-year old notorious gamer oblivious to deep understanding of how things work would ask - it isn't a question that a person with a PhD would ask or should ask. Clark's answer to the question is in the same category as your question (i.e: his answer isn't an explanation, and entails a dubious claim about performance of code recompiled for Zen 5/6), while 1 of the primary reasons of having 2x.4wide decoders and 2x.6wide µop cachelines in Zen5 is to overcome compile-time limitations.
There is almost zero useful technical information in this video. The claim made by Clark that "recompiling software for Zen 5-6 will lead to IPC gains larger than 16% on average" is at this point just a mere conjecture that isn't being accompanied by evidence.
The evidence is that they have a dual fetch decode pipeline. I don't think old applications can take advantage of that second pipeline. You need compilers to optimize for dual pipe fetch decode.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One µop cacheline in Zen5 is 2*6=12 µops wide, up from 9 µops in Zen4 (note: the Wikipedia page about Zen4 is misleading in this respect and contradicts Zen4 slides published by AMD). From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One pop cacheline in Zen5 is 2*6=12 pops wide, up from 9 pops in Zen4 (note: the wiki-pedia page about Zen4 is misleading in this respect and contradicts Zen4 slides published by AMD). From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One pop cacheline in Zen5 is 2*6=12 pops wide, up from 9 pops in Zen4. From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One micro-op cacheline in Zen5 is 2*6=12 micro-ops wide, up from 9 micro-ops in Zen4. From the ratio 12/9 = 133% one can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
Get your story straight. They said.. "The socket change also sets [AMD] up nicely for future development and scalability of the Threadripper platform". They didn't say dick all or make any promises about TRX40 for consumers. But true to their word they later released the 3990x and also 2 generations of threadripper pro parts with a new variant of that socket. You can twist how *you perceived it* whatever way you like but it doesn't change what they said and make it incorrect.
@@tomstech4390 100% WRONG !!! AMD bait and switched on that well-known(!!) infamous "long term support" promise lie, and in doing so, 100% destroyed their ENTIRE enthusiast userbase. They royally shafted BOTH X399 and TRX40 purchasers...every one of them!
We are disappointed by amd gpu. The amd team is inferior. It is time to move onto arm based core. I am sure amd is designing new arm core but they may not be good
![[35] Ian Interviews Mark Wade, CEO Ayar Labs](http://i.ytimg.com/vi/oJ7Nl_XhmOM/mqdefault.jpg)
These 5min was great, I could also sit and listen for 50min!
Maybe at Hot Chips :)
@@TechTechPotato Make it happen :)
5min of stupid amd marketing and awkward head engineer reaction to the right question "why its just 16%" after 2 years of "progress". he knows amd gutted 9000 to make discounted 7000 look better in comparison. no more clocks, no more transistors, no more cores, no 3d-vcache. amd literally GUTTED zen5 to not compete much because intel/qualcomm aren't competing at all too.
so amd does intel now. 14nm+++++++++ 12-14 "gen" with minimal uplift now from amd.
"Zen daddy" clearly abbreviates to zaddy.
widen my backend, zaddy uwu
Give me more memory bandwidth zaddy 😰
I love his attitude.
Sometimes it's the "weird" questions that trigger the nugget, because in order to give the answer to it, you might have to explain it differently than the last ten times you've answered questions that are similar but not identical. And then you go "wait, why DID we do it this way?"
And it's not always ground breaking questions. Sometimes it's just questions that challenge the "that's how it's always been". Best example I know of isn't mine - it's an anecdote I heard from a teacher, and the grumpy face he put up as he told the story just showed how angry he was that HE hadn't asked the question.
He worked in a machine shop, and he was showing two 9th or 10th grade classes around the various shop buildings they had. They walk into one production hall, and as they walk in he gestures towards a very large water bath and says "be attentive, because otherwise you'll" and is interrupted by a loud thump followed by angry swearing, as one of the teachers had banged their shins into a drain valve at the end of the water bath.
"Don't feel too bad about it - the rest of us do that once or twice a year as well, and I've worked here for more than ten years."
Then one of the students raised a hand and was told to ask their question.
"Why don't you just move the valve to the underside of the bath, so you don't bang your shins against it?"
And it's now 30 years on, and I can still see my teachers angry, contorted face as he paused while telling the anecdote.
The valve was moved at the end of the work day, with the boss himself doing the work. Apparently the boss had ended up in the ER due to the valve at one point, so it was revenge I guess.
I collect retro PCs and their CPUs. It's nice knowing that my 7800X3D I'm using has some of the same engineers that designed my K6-2/3 CPUs. Wild!
That's exactly my thought at that point in the interview - followed by a glance to the shelf where my good old K6-2 is on display. 😊
we love mike
I do enjoy snippets where you get to see the enthusiastic people that work at these various technology companies.
These short chats with industry VIPs are highly entertaining. Thanks for doing these!
Just like to say I have always been a very happy AMD system customer, and that has to be down to people like Mr Clark who have shaped the company and encourage this very positive, engineering-focused attitude. I can honestly say I've had nothing but good experiences - and I've always built my own systems. (I'm an electronics engineer by trade.)
Zen daddy❌
ZADDY ✅
He might be called zen daddy due to the number of buttons undone on that shirt....
So very application specific and will benefit more applications under development. Applications with rich customers, your world spins faster. Kudos to AMD.
Mike is such a cool dude! Can't wait to test drive the Zen5!
Zen ages like a bottle of fine red wine, Intel ages like they added a dose of blue antifreeze, eventually you are going blind.
I grew up, so to speak, on P2/P2 & quickly dabbled in K6-2 350 to K6-3 500 before going back to a I5- 3750k (great CPU) that lasted till Zen Ryzen1600X on a AX370 K7, which is still running well with a 3600X today.
Only just purchased a 7600x, Tomahawk & FlareX again, another Samsung, 990 Pro. Yet to be installed.
The only regret I have is not spending the $6000 spare I had on AMD shares at the beginning of Zen. I always like an underdog, they put that extra effort in & are often willing to take a chance on change. O well, at least Zen got me out of the upgrade silly-cycle. They have provided reliable service for years.
Maybe he'll be "Mac Daddy." Nope, that doesn't seem right. 🤣
I'm getting major Robin Williams vibes from Zen Daddy
I want to imagine that some of the am29k engineers are working on Zen, too. Not sure if that's too big a stretch.
Zen5 will mature like fine wine.
You mean AM5 socket?? Just like the legendary AM4?
it'd be intel 14nm+++++++++ from now on. 0 progress and milking the market because no corporation wants to actually compete and drop prices.
@@rawdez_ what are you even talking about
@@MissMan666 amd just REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to this techtechpotato Mike Clark interview :/. thats it.
then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd
AMD is doing intel now
@@MissMan666 AMD is doing intel now.
they REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to this interview. then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd
Intel needs people like Mike Clark right about now.
intel has their own starts, don't worry
@@vladmihai306 Intel is incompetent though. They released defective i9 processors and they are staying silent now.
@@cemsengul16 that's more because of the focus and bad management decisions
AMD was also in the hole in 2015... before Lisa came. And Mike Clark was there also and still AMD had the buldozer fail. So it's more about the targets and the team and not because a company lacks talent
@@vladmihai306 Of course AMD had their share of troubles too in the past. The difference is they quickly acknowledged it.
Imagine where we would be today if it wasn't for Zen. Hopefully AMD will not get lazy with a "good enough" approach.
LET’S [EXPLITIVE]ING GOOOOO
Great video Ian, Mike seems like a great guy to chat with.
Calling 16% IPC small is kind of ridiculous. That's a huge gain for a mature architecture.
no its not, amd just REMOVED everything that made 9000 faster. no more clocks, no more transistors, no more cores, no 3d-vcache. they've literally GUTTED 9000 to not compete much because intel/qualcomm aren't competing at all too. all we've got is pure node shrink and some architecture improvements THAT DON'T WORK YET "because software is bad/old" - according to techtechpotato Mike Clark interview :/. thats it.
then they'll just add it all back gradually and sell it as zen 6-7-8 "upgrades" for years. zen 8 or 10 would be what zen5 was supposed to be. thats how amd "platform longevity" works - seling the same stuff multiple times but less gutted for years. obviously thats NOT Mike Clark's zen daddy's fault, thats on amd
AMD is doing intel now
9000 only exists to make discounted 7000 look better, 7000 which almost nobody bought because there's no faster affordable GPUs to make a difference with 5000 ryzen. now they hope to sell through 7000 because 9000 makes 0 sense.
and there's no faster affordable GPUs because main amd business is selling cheap to make obsolete chips for consoles to sony/ms which is also not interested in progress with PC GPUs because consoles. progress with PC GPUs would make 2016-level hardware in consoles look VERY BAD in comparison. so amd nerfed their PC GPUs too e.g. halved Infinity Cache and set unreasonable prices because feature set isn't even close for how overpriced it is.
all what ayyymd has to do is just connect SSD to a GPU chip directly (like they already do with obsolete chips in consoles and did on their PRO SSG card in 2016) and PC GPUs can get TERABYTES of 'VRAM' like 2-8TB i.e. WAY BETTER DirectStorage without long PCIe bus lag/latency => way better textures/models = movie-like graphics. but 1) its the endgame GPU, the last GPU you will EVER need to buy, so nobody wants to actually make it and sell it 2) it will kill consoles and GaaS businesses for amd, nv, ms, sony. thats why corporations are just milking the market with obsolete cheap-to-make overpriced 3-4 times hardware - they've got too close to the end of progress with what they sell. + selling the same old tech year after year without spending much on R&D is way more money than making actual progress = prices on old tech don't drop.
@@rawdez_You don't understand ANYTHING of these technologies and make it very clear for everyone.
great stuff
Interesting point about software needing to catch up to the hardware! I wonder if AMD will try to contribute enhancements to compilers to take advantage of this stuff... it might be difficult because you'd have to justify giving up performance on older, slower chips in order to make the newest chips faster. Well, either that or ship another variant of the logic that only runs on the latest chips - might be justifiable for some applications but probably a hard sell for most.
Zen Daddy! ❤🔥
Nice one.
I'm a bit optimistic that Zen 7 will be on AM5.
Depends. AMD have already proven they will be anti-consumer when they want - they 100% destroyed their entire enthusiast userbase with a deliberate bait and switch for their previous Threadripper non-pro platform, TRX40, by EOL'ing it not long after it was released - despite that now infamous "long term support promise".
My own belief is that AMD will bring out a new socket for Zen 7, incompatible with earlier CPU's.
That sounds overly optimistic, not just a bit. Not only in the number of generations (4 instead of 3 on AM4) but also in terms of years. Zen 3 launched 3 years after Zen 1. But Zen 7 will come in 2026 ? 2027 ? Which is 4 - 5 years after Zen 4 (2022). That's A LOT more, because you'll have to support it at least 1 extra year after the initial launch, as it's basically guaranteed that not all CPUs and APUs will be launched at once.
And the board parteners, ASUS, Gigabyte, MSI and the rest, they won't welcome that. It will be a tremendous pressure on the early cheap motherboards to be made to be compatible with the extra generation, a big problem since those boards have really low profit margins, so 1 year of extra support of BIOS revisions is going to eat this into the negatives.
If you think about it, other than being a very nice thing for us, the consumers, it is really stretching it way more than it is designed for and that the industry is prepared for. Something like this has to be planned before, and they barely confirmed... if I'm not mistaken, the Zen 6 support.
Excellent short video. Keep your thumbnail game like this and I think you'll get way more views each time
Thanks Ian, good to see this! Wondering, who would be the "GeForce Daddy"?
This should be referring to Intel, not GeForce
😂@@furkantokac
that's Jensen Huang and Zifeng Su
@@erkinalp Uhh no. Mike Clark created Zen 2 chiplets, which has made AMD $100+ billion in market cap and a bright future. NVidia has someone or some group of designers that has been kicking-ass in GPU design for years now, and wiping the floor with AMD GPU design. Who is this person/people?
You be
What ever happened to the AMD patents for 4 threads per clock ..
That you got a patent for something does not mean it is feasible already or that other limitation/problem need to be solved first and that can take years.
Where is the rest? :P
Amd user since k5
My first desktop was Intel and first laptop was AMD (probably A9).
Second laptop again on AMD i.e. R5 4600H.
15% is the target and Minimum Viable Product is an approach that all but guarantees gas in the tank for the next architecture while after getting the 15% lets you target bringing down costs to manufacture and heat to again make that 15% next year without hiccup. 15% is what is needed as the x3d will be out by lunar lake and likely AMD could win a price war v.s. lunar even if Intel has a Minimum Awesome Product moment. I'd also like to say once you hit the 15% you can focus on stability in all apps and software two small things with huge impact so nice AMD.
isn't Jim Keller helped built the Zen architecture?
Yes indeed.........Jim Keller is one of the mastermind behind the Zen architecture.
@APU-iGPU - I've asked both. Mike is the father, Jim is the crazy uncle.
@@TechTechPotato 😂.......thank you 🤟
Please move over to gpu division and do to nvidia what youve done to intel, please
I've been using AMD since the 486 Overdrive :)
Why is the video so short?
only had 5 minutes
sik vid!
a bit short.
Tell them changing names is fkin stupid and a sign for the customer you are trying to hide something because you messed up previously
That is one of the thumbnails of all time
Waiting for AMD cpus to use less power in idle.
This is one if the downsides of a chiplet architecture as you need more pJ/bit when you need to move the data out of the die through the organic package interconnect and back.
That is why for the mobile SKUs they are monolithic as idle power is much more important.
Using an silizium interposer or bridge like EMIB would help but also increases cost and lowers yield.
thx for removing the shitty AI thumbnail
I just have to say it, that AI-like thumbnail is very cringe. Can't wait for this fad to ... fade away.
I'm using UA-cam's test and compare on thumbnails. There are two others, it'll default to the one that performs the best soon
@@TechTechPotato Oh, thanks for the reply! That makes sense.
why 5 min not 50 mins....
Why use awful ML generated thumbnails 😕
pretty sure the 16% avg increase in ipc is because of the imc/io die and the IF not being able to run that fast still, or can it?
If that were the bottleneck, then monolithic mobile parts will show a significant IPC difference (which I don't believe that is the case)
@@egalanos no, over the zen4 it is probably why we see the small ipc uplift, because it is held back by the io. the mobile parts are cutdown cache wise so the perf is very gimped, so no.
if zen4 had an monolithic sku with 32MB of level 3 cache and the better IF we would see better perf over what zen4 have.
If zen5 was monolithic with all the improvments it has over zen4 it would be even better that what we get now with zen5.
but in some aplications, ie many synthetic tests the test run pretty much from the cache so the need for better imc would not be there.
@@PillokunYou don't understand how this works.
Please learn more first before having so much opinion without understanding the basics.
@@frankstollar8492 ipc is not a number fixed in stone. It changes depending on the application. It simply means how much work it does or additional perf it has over the sku compared to it. U-code, application improvements for the u arch, and even cache and ram frequency might improve the ipc. For instance ipc of 7800x3d in games is highest because the cores don't need to wait for ram and can execute much faster and u get higher perf.
@@Pillokun I think I understand more of this subject than you do obviously.
Amd CPUs should support 4000mhz fabric clock speed
He didnt really say much, im not sure what the point of this video is apart from clickbait...
He said a lot tbh.
@@TechTechPotato The fact is that he said very little in this interview. Watch the ChipsAndCheese interview with the same person instead.
Watch the C&C video? I filmed it! I'm literally the cameraman. Notice how the microphones are the same and the water bottles haven't moved.
@@TechTechPotato You should watch the C&C video nevertheless, multiple times, because you clearly don't understand the difference between your approach to making tech videos and C&C's approach to making tech videos. The question you asked "Why is it only 16% IPC" is a question that a 15-year old notorious gamer oblivious to deep understanding of how things work would ask - it isn't a question that a person with a PhD would ask or should ask. Clark's answer to the question is in the same category as your question (i.e: his answer isn't an explanation, and entails a dubious claim about performance of code recompiled for Zen 5/6), while 1 of the primary reasons of having 2x.4wide decoders and 2x.6wide µop cachelines in Zen5 is to overcome compile-time limitations.
garbage chiplets still got AMDipp
There is almost zero useful technical information in this video. The claim made by Clark that "recompiling software for Zen 5-6 will lead to IPC gains larger than 16% on average" is at this point just a mere conjecture that isn't being accompanied by evidence.
The evidence is that they have a dual fetch decode pipeline. I don't think old applications can take advantage of that second pipeline. You need compilers to optimize for dual pipe fetch decode.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One µop cacheline in Zen5 is 2*6=12 µops wide, up from 9 µops in Zen4 (note: the Wikipedia page about Zen4 is misleading in this respect and contradicts Zen4 slides published by AMD). From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One pop cacheline in Zen5 is 2*6=12 pops wide, up from 9 pops in Zen4 (note: the wiki-pedia page about Zen4 is misleading in this respect and contradicts Zen4 slides published by AMD). From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
@@kazedcat Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One pop cacheline in Zen5 is 2*6=12 pops wide, up from 9 pops in Zen4. From the ratio 12/9 = 133% you can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
Applications, both old and new apps, will be able to automatically take advantage of the "2nd fetch decode pipeline". In most cases, the average size of a basic block is an inherent property of the source code (of the algorithm) being compiled and compilers in most cases cannot do anything about it. Yes, you can change the average size of basic blocks if you rewrite the source code (adjust the algorithm) by hand, but unfortunately such an adjustment in most cases requires higher-level thinking that no existing compiler is capable of yet. Thus, recompiling for Zen5 can achieve only a rather small speedup (about 1-2%, albeit speedup in case of AVX-512-friendly code can be larger). A caveat here is that the number of cases in which code emitted by compilers with -march=native actually runs slower than previously is non-negligible. One micro-op cacheline in Zen5 is 2*6=12 micro-ops wide, up from 9 micro-ops in Zen4. From the ratio 12/9 = 133% one can derive that Zen5 can fetch+decode at most +33% more x86 instructions per clock than Zen4. In this respect, the 16% Zen5 IPC uplift self-reported by AMD is a very good overall result.
Nice job you did on TRX40, 100% destroying your entire enthusiast userbase with that infamous bait and switch broken promise ;)
This is the cpu architect, not the platform architect. But gg
Get your story straight. They said.. "The socket change also sets [AMD] up nicely for future development and scalability of the Threadripper platform".
They didn't say dick all or make any promises about TRX40 for consumers. But true to their word they later released the 3990x and also 2 generations of threadripper pro parts with a new variant of that socket.
You can twist how *you perceived it* whatever way you like but it doesn't change what they said and make it incorrect.
@@tomstech4390 100% WRONG !!!
AMD bait and switched on that well-known(!!) infamous "long term support" promise lie, and in doing so, 100% destroyed their ENTIRE enthusiast userbase.
They royally shafted BOTH X399 and TRX40 purchasers...every one of them!
If you get any time with AMD GPU/AI engineers you need to ask why their drivers are trash.
2 years for this performance. LOL
are you just trolling or was that comment serious?
@@frankstollar8492 Very serious. ARL, with less threads, will beat Zen 5 easily.
@@carlhil2 I very much doubt that especially in multithreading without SMT. Not to talk about efficiency.
@@frankstollar8492 Changed your mind yet?
@@carlhil2 nope
Wasted my time
Don't let the door hit you on the way out
@@TechTechPotatoDo you like your potatoes the way you like your haters? i.e. roasted
@@TechTechPotato don't stand close, it swings back
third
We are disappointed by amd gpu. The amd team is inferior. It is time to move onto arm based core. I am sure amd is designing new arm core but they may not be good
What you said doesn’t make sense
AAAAAAAAA
Your 14900k is corrupting your comments, all you wrote is nonsense!
@@visitante-pc5zcAAAAAAAA
You want AMD to use a CPU core for their GPU's???
third