Yes, but things have changed: when you're starting from "low", it's much easier to progress by large leaps. When your uarch is solid and process doesn't provide a lot of improvements, you're bound to advance more slowly.
And yet Zen3 and Zen4 were each bigger IPC increases than Zen2 was.Fruit was within reach without a ladder.
Yes that is true but you have to look where the bar was. Intel was ahead back then and AMD was simply catching up. AMD had some low hanging fruit left, Intel had picked most of their by the time Raptor Lake came around.And yet Zen3 and Zen4 were each bigger IPC increases than Zen2 was.
If they both fail that hard they simply will not be competitive for consumer workloads.Yes that is true but you have to look where the bar was. Intel was ahead back then and AMD was simply catching up. AMD had some low hanging fruit left, Intel had picked most of their by the time Raptor Lake came around.
My point is that AMD did quite a bit of catching up because they were so far behind.
Now we have Lion Cove and Zen 5 and outside of gaming (and Intel's memory/latency issues with LC/tiles) they are very close in IPC. I will be super impressed if either one can make a jump significantly better than the other. They'll both get something around 5% IPC or so next gen from architectural improvements. If one "fails" it'll be because they get 3% and the other gets 7%. You'll see.
Or I'll see and you'll be right! Either way it'll be a fun reveal!
What do you mean client workloads don't matter? Client was over 25% percent of AMD's 2024 revenue.Stuff that doesn't matter.
Great.
Did they also increase core count and frequency, and to which extent?And yet Zen3 and Zen4 were each bigger IPC increases than Zen2 was.
They don't matter enough for AMD to design a core around them.What do you mean client workloads don't matter?
I don't think one data point makes a trend. How many other duff generations have there been before future generations just the myth. Every Intel generation since sandy bridge?I'm confused. Zen 4 to 5 and Raptor Cove to Lion Cove brought less than 10% IPC gains (a lot less for LC). Clocks were also stagnant. This is the latest data/generation, which support my low hanging fruit opinion.
We shall see if the next generation bring a 20%+ IPC gain and increased frequency. The last generation was only "cleaning up the edges."
I WANT to be proved wrong! I hate this reality.
a) nanoflexThat node can get increased frequency by using fin flex.
Not really.There are other ways to more performance now, that didn't exist before.
More avenues to scaling exist now, for performance. Also... On the topic of dnsity. Have a look at the latest RDNA4 density numbers vs RDNA3. Big gains still have been found. Though that's not the main point, which is that there are more ways to eek out performance.The difference being that in the past, transistor budget and power budget doubled every 18 months. It is quite easy to get a large boost when you have wider everything, and deeper everything, and more complex logic everything over the previous generation.
Today, we are seeing what? 15% higher density per generation? .... and even this only after 3 years. Additionally, the cost of going from one node to another is on an exponential curve, so that 3 years may soon look more like 6 years.
I could be wrong, but I think the days of big gains every generation are over for good.
Didn't say it was free... Costs are going up right now, though they are being kept in check, to a degree, by 3D integration. I expect usage of mixed nodes to increase in the future to continue to (partly) offset costs. My points are more about scaling generally, rather than scaling at fixed cost.a) nanoflex
b) not free
Not really.
a) nanoflex
b) not free
Didn't say it was free... Costs are going up right now, though they are being kept in check, to a degree, by 3D integration. I expect usage of mixed nodes to increase in the future to continue to (partly) offset costs. My points are more about scaling generally, rather than scaling at fixed cost.Not really
there's literally only one vendor practicing 3D at any real scale lmao.they are being kept in check, to a degree, by 3D integration
Frequency yes, core count no. But they also added 3D V-cache, and achieved 20% IPC per generation with only one node jump between the two of them.Did they also increase core count and frequency, and to which extent
Look at Apple silicon.Now we have Lion Cove and Zen 5 and outside of gaming (and Intel's memory/latency issues with LC/tiles) they are very close in IPC. I will be super impressed if either one can make a jump significantly better than the other.
I mean, I don't necessarily disagree, but I don't think gdansk was suggesting that they do.They don't matter enough for AMD to design a core around them.
Fat 3M L2 would be a boon for client stuff, yet you ain't getting any L2 bumps until like 2028 (generously).
AMD sticks to their guns in CPU and GFX, generally speaking.
Yep. It's at the early part of the curve. I doubt it will stay that way forever....there's literally only one vendor practicing 3D at any real scale lmao.
I don't think Apple M runs Windows with very good IPC, right?
It is if the OS has constrains due to legacy reasons.IPC is not a property related in any way to the OS!
Exactly. It is meaningless to compare the IPC of one processor running a different OS and appication code base to another completely different CPU on a different OS running a different code base for the application.It is if the OS has constrains due to legacy reasons.
how about GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=off" and GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=auto"?Saying that IPC is reduced by the operating system is like saying that my car's horsepower goes down when your mom gets in. The power isn't reduced, there's just a heavier load so it goes slower.
That's still just changing the software that's running on the CPU. It doesn't change the number instructions that the CPU is capable of executing in a clock cycle. IPC by definition refers to the hardware capabilities, not software.how about GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=off" and GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=auto"?
Here is where I would disagree. Operating Systems do not make a difference to the CPU IPC nor to its performance drastically. Macs when on Intel had the exact same IPC and performance as macOS when the CPUs were tested on Windows on the same Mac.Exactly. It is meaningless to compare the IPC of one processor running a different OS and appication code base to another completely different CPU on a different OS running a different code base for the application.
If the Apple IPC wants to make you move to that ecosystem then fine go have at it and leave x86 behind.
But to compare the two would be like comparing the efficiency of air travel to trains to automobiles. They are comparable only in the sense that you pick the best option for you but you don't put down automobiles for not being trains or planes or vice-versa. You compare within a category. This category is x86 and more specifically Zen 6.
You can throw stones from the Apple side of the road to the x86 side all day long but at the end of the day you're still on the other side of the road.
You make a valid point. But I guess Windows can do such things to, no? I'd expect all OS to have very similar sets of mitigations, though I might be wrong.how about GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=off" and GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=auto"?