I'll be ordering one cpu with 4 bitching fast serial cores and 40 slow-ass power optimized cores. I'am willing to pay 350 euros. It's a good offer - you take it.

lmao at the post above 🙄

Amd should just focus on zen4 early next year. Until alder lake they are still on top as it is.

Noisiv:

I'll be ordering one cpu with 4 bitching fast serial cores and 40 slow-ass power optimized cores. I'am willing to pay 350 euros. It's a good offer - you take it.

Well you do not need more than 4 full cores for gaming. The rest 40 tiny will "support" background, OS and I/O operations. Still bang for buck. 😛

itpro:

Well you do not need more than 4 full cores for gaming. The rest 40 tiny will "support" background, OS and I/O operations. Still bang for buck. 😛

no no-no... 4 bitching fast cores for pig coded games like WoW, ARMA, Flight sims etc. Games which are either not well threaded or otherwise demand high IPC/thread. but 40 slow, power-optimized cores are simultaneously used executing less occupied threads, and not just background/OS. So you end up with great serial speed, great parallel throughoutput (due to sheer number off cores) and great perf/Watt 😀

I've been saying this for a while. There's no need for a Zen3+ now that Rocket Lake is out. AMD should focus on their next architecture, much like Intel are doing. RL was nothing but a stop-gap product released in an attempt to narrow AMD's performance lead. Introducing new SKUs when you still haven't fulfilled original demand, and with a CPU line that might only yield insignificant performance gains is a waste of time and silicon better used on your current product nodes. So... sounds like big-little cores are the future then. I don't know how I feel about that. It sounds like from a pure gaming performance standpoint we might be stagnating for a bit again.

Zen3+ can't be cancelled, it was never a thing to begin with.

Did Zen 3+ existed outside the rumor mill? Talking about little.big, ARM approach without SMT is proving to provide a safer enviroment, similar single thread performance, smaller cores and restricted power consumption. So little.big can be a solution to retain multithreading power while increasing single core numbers without making them too much bigger. Intel's approach, mixing hyperthreading with small cores is kind of new. AMD told there is too soon for them to jump in, but nowadays they don't talk too much about future releases, what I think it's ok.

lmao big.little... outside mobile and low power laptops there is no need at all of this.

Hilbert Hagedoorn:

First, this entire news post is based on hearsay, so take it like a rumor. The first one is that WARHOL, the Zen3 optimized Ryzen 6000 series might have been canceled. Currently, ... Rumors: ZEN3+ Cancelled and ZEN5 going for a BIG.little architecture

The tittle gave me a chuckle. Its not BIG.little in the sense that is an ARM specific architecture but then its called big.LITTLE. I assume you know all that so +1 for being cute.

haste:

BigLittle cores in PC desktop? Oh hell no.

The rumor is for an APU so its likely its not a desktop chip or if it is its targeted at lower end desktops for business etc.

Funny how many people here think they know better about what's best. I for one look forward to x86 CPUs getting this kind of architecture. Worst-case scenario, we'll get cheaper products with lower power consumption. Wow, what a joke of an improvement, right!? /s Best-case scenario, the little cores can be overclocked to crazy speeds and yield better performance, because most applications don't need most of the instructions x86 comes with. This is why ARM has been taking off in the server market and yields such amazing performance-per-watt for Apple. Ditch all the baggage and you can get something great. x86 can't afford to ditch everything due to compatibility problems, so, they can just provide simpler cores instead.

SMT is meant to full-load the pipeline (and so having a longer pipeline that really can performs near 100%). big.liitle will never remove its benefits, it is just for idle things. and on desktop we don't need it at all, having 2-3W vs 4-5W is no real benefits, all the rest of devices will consume far more. Also SMT advantage is to remove cache access stalls, while big.little produce cache stalls. We already saw intel experiments on this, and was a disaster in performance terms. On desktop we have better power savings reducing by 5% the screen brightness or just removing some crap software in background like the fraud of antimalware software.

Luc:

Did Zen 3+ existed outside the rumor mill? Talking about little.big, ARM approach without SMT is proving to provide a safer enviroment, similar single thread performance, smaller cores and restricted power consumption. So little.big can be a solution to retain multithreading power while increasing single core numbers without making them too much bigger. Intel's approach, mixing hyperthreading with small cores is kind of new. AMD told there is too son for them to jump in, but nowadays they don't talk too much about future releases, what I think it's ok.

I'm actually glad it's never existed/cancelled so I can proceed with Zen 3. I'm not in a rush to buy a new motherboard and RAM so this is a positive for me :S

@Alessio1989 aaah, glad to see you crystal ball finally gave you a prediction of that billions of ppl on this planet want. and please do look up the definition of fraud, as you clearly dont understand its meaning. i have not been defrauded by any free av/am sw in the past 15y (using the known stuff), and more trouble with leaks/breaches at yahoo/visa and the like.

antimalware software are a fraud. the only real risk is the user. antimalware do the exact things of the software they claim to fight, just with different shades (otherwise you would not pay for them 😉 ). And most of their efficiency is outperformed by OS kernel mitigations like ASLR, CFG etc.

Fox2232:

Look at bright side of things. It is light at end of tunnel for intel. When you have big.LITTLE, SMT/HT becomes useless. (SMT/HT delivers like 25% extra performance per core on average. LITTLE core may deliver even 50% of big one.) So, all those lovely side channel attacks are gone in instant. Then it is not really that bad in terms of transistor efficiency. LITTLE cores may be quite bigger than portion of CPU that enables SMT/HT, but they not only deliver higher performance, their use enables shrinking and simplification of big cores. I would take 8 big + 8 LITTLE cores over 8C/16T w/ SMT/HT. Only problem is execution capability. One may think that many LITTLE cores replace need for many big cores. But that's false assumption. If we have only 4 big cores, we are bound to run into main weakness of LITTLE cores. And that's limited instruction set. When there are threads which need big instructions, they can only run on big cores. And it may happen that many games/applications will suddenly live on mere 4C/4T system even if there are additional 16 LITTLE cores. This step may be quite interesting. Changes may enable even chiplet with 12/16 big cores and chiplets wit 24/32 LITTLE cores. - - - - For laptop APUs that will have RDNA2/3, I would not mind 4 big + 4 or 8 LITTLE. Because chance that CPU will limit GPU there will be small. But in desktop where GPUs can pull hundreds of fps, having only 4 powerful cores is bound to bite people into arse at some point.

If you look at Apples M1 obviously this design works for low power. The M1 is an excellent example of making really wide performance cores(way larger than Intel and AMD cores) then using little cores to provide extra threads. Intel's new big desktop CPU(APU) the 11900k has 6bn transistors and Apples M1(4 perf cores + 4 small cores) has 16b transistors. These densities of transistors will make having really powerful cores an option and it does look like in low power situations tacking on lower performance cores is a great option especially since said lower power devices spend a lot of time doing light tasks like web browsing, checking email, spreadsheets etc so you realize lots of power savings keeping those big cores powered down most of the time.

I'll buy that for dollar

tty8k:

They can and probably will release Zen3+ because won't be anything else than 100MHz + for the actual lineup. Basically same chips better binned. Big.small is the way to go since windows will most likely get optimized for it (Intel) and also because no matter how small the manufacturing process will be, the consumption/cooling curve it really close to the max at this point, we can't have another box next to the pc just to cool the processor. Anyway, desktop will be more and more a niche product, now laptops cover the productivity area just as good so it's only pc gamers that's left really (which most turned to console since the ridiculous PC prices).

Get windows optimized for "it" requires assistance from Microsoft and that will be key to the viability of this idea. This would require a fair amount of changes to windows internals, especially the scheduler. Currently it has no concept of heterogeneous processors. It knows about SMT and the idea of primary and secondary cores and schedules on primaries first but this would be considerably different. Also, from an architectural point of view, would these "little" cores be fully x86 compatible? I think they would have to be or the changes to software would be huge. That raises the question, what does a "little" X86 core look like? I would guess that it has no AVX anything, smaller cache(s), and is stripped of other advanced features. In the end, I really don't see that resulting in much saving of power. That is, unless those cores can be clocked at a MUCH lower rate. That could actually work too since it essentially exists today. There is still the issue of windows knowing what cores are of what variety and that requires a lot of changes to software. Then the question is what processes and/or threads will be scheduled for the little cores? Will that be done automatically (by the OS) or will developers have to flag processes and threads for their processing requirements? Doing this automatically could be difficult if the cores are really that stripped down. I think a much more feasible approach to this is what I mentioned earlier - vary the clock rates but do it more drastically. One approach is to schedule threads that execute at low priority on cores that can be clocked very, very slowly. If the clock can be slowed to a factor of 8, or more, that could save a LOT of power. This could be done with no changes to any application code and virtually no changes to processor architecture since they would still have homogeneous cores. I like that idea better than mixed B-L cores.

Gomez Addams:

Get windows optimized for "it" requires assistance from Microsoft and that will be key to the viability of this idea. This would require a fair amount of changes to windows internals, especially the scheduler. Currently it has no concept of heterogeneous processors. It knows about SMT and the idea of primary and secondary cores and schedules on primaries first but this would be considerably different. Also, from an architectural point of view, would these "little" cores be fully x86 compatible? I think they would have to be or the changes to software would be huge. That raises the question, what does a "little" X86 core look like? I would guess that it has no AVX anything, smaller cache(s), and is stripped of other advanced features. In the end, I really don't see that resulting in much saving of power. That is, unless those cores can be clocked at a MUCH lower rate. That could actually work too since it essentially exists today. There is still the issue of windows knowing what cores are of what variety and that requires a lot of changes to software. Then the question is what processes and/or threads will be scheduled for the little cores? Will that be done automatically (by the OS) or will developers have to flag processes and threads for their processing requirements? Doing this automatically could be difficult if the cores are really that stripped down. I think a much more feasible approach to this is what I mentioned earlier - vary the clock rates but do it more drastically. One approach is to schedule threads that execute at low priority on cores that can be clocked very, very slowly. If the clock can be slowed to a factor of 8, or more, that could save a LOT of power. This could be done with no changes to any application code and virtually no changes to processor architecture since they would still have homogeneous cores. I like that idea better than mixed B-L cores.

Intel is already shipping heterogeneous processors with lakefield, so I'm not sure why you think it has no concept of it. It's not known if they'd be x86 or not but I don't see why they would be, Windows ARM translation layer is extremely efficient and ARM is architected from experience with power efficiency. If your goal for the small cores was specifically power you'd definitely go ARM.