> Unfortunately, however, because Windows sees all of the cores as identical, it also has no proper insight into energy efficiency here. Specifically, Windows has no idea that the Zen 4c cores are meant to be more energy efficient, so it will be making scheduling decisions based solely on workload/frequency metrics. This means that AMD is not able to take full advantage of the energy efficiency advantages offered by the Zen 4c CPU cores, as Windows isn't able to explicitly schedule threads on the more efficient cores. (An issue Intel gets around with their more meddlesome Thread Director)
Given that they are on feature parity with Zen 4, but trade higher clock speeds for density and efficiency - will we see the efficiency if Windows doesn't know any better?
Would Linux be able to do any better if it can tell the cores apart?
Yes, Linux is aware of asymmetric cores and can schedule more efficiently. big.LITTLE core architectures are more common in ARM systems, so Linux developed that support over ten years ago: https://lwn.net/Articles/501501/
The official documentation is at https://www.kernel.org/doc/html/latest/scheduler/sched-energ... . I don't know if the kernel already has an energy model that can apply to the Zen4/Zen4c cores, probably the model/instrumention must be explicitly added.
I am not an expert, but I believe it still requires some manufacturer effort on Linux. I bought an Alder Lake system pretty close to launch, and I had to wait a few months for kernel-side Thread Director[0] to fix asymmetric scheduling. Performance was really janky before that update, even though the power consumption and iGPU seemed fine. Nowadays things are fine, though I'm not sure how much of the asymmetric support was already in the kernel.
> is there any reason Windows can't receive a patch to be able to do so?
Probably not, given that Thread Director also runs on Windows AFAIK. AMD could probably cook up a solution if they needed one, but their E cores look pretty powerful from the get-go. My guess is that it won't need such a huge patch to perform well.
Windows 11 knows how to use Intel performance and efficiency cores thanks to Intel providing Intel Thread Director which gives some hints to Windows 11's scheduler.
AMD, from what I can tell, doesn't provide an equivalent to Intel Thread Director so Windows 11's scheduler has to work blind not unlike Windows 10's scheduler when working with Intel performance and efficiency cores.
So all else being equal, it's reasonable to assume Windows 11 will not take full advantage of AMD's performance and efficiency core architecture because the scheduler is working blind.
> AMD, from what I can tell, doesn't provide an equivalent to Intel Thread Director
Isn't that simply because AMD so far didn't have any heterogenous cores and they will quite possibly/likely work with Windows to add support for them (just like Intel did)? It might take some time, but it seems needlessly pessimistic to expect that this won't happen in some form.
But why should it be on AMD? This needs to be a part of the OS as it is like in Linux, or as a user you're penalized for picking the company with less solid connections to Microsoft and less budget available to do something like Intel's thread director (which is how Intel's mixed cores are "supported" by Windows). Windows doesn't have any native support for heterogenous cores. It just takes the CPU's advice on what to do. That seems crazy to me.
Well, who adds support for this into the Linux kernel? It's also the CPU vendors.
While there is certainly a need for some common scheduler logic, there also needs to be per-vendor or even per-model support added, since the OS first needs to even figure out which cores are which and each vendor's efficiency cores have different characteristics.
AMD can't do that for Windows. Why do they have to add a hardware component to their CPU's to do it like Intel can afford to?
> Intel’s Thread Director controller puts an embedded microcontroller inside the processor such that it can monitor what each thread is doing and what it needs out of its performance metrics.
Linux literally has native support for heterogenous cores that works for both AMD and Intel. There's a world of difference between contributing to the kernel to ensure their CPU's work well and AMD being forced to put a microcontroller in their CPU and develop their own CPU-internal scheduling system.
I think we're well past the point AMD is the "small indie dev" to "big corpo house" Intel. If AMD refuses to do what is necessary to fully bring out the performance of their hardware, that's not on Microsoft.
I see Intel Thread Director quite similarly to how hardware manufacturers provide their own drivers. Sure, Microsoft could provide some generic driver, but that's not going to make full use of that hardware because only the manufacturer fully knows what's going on.
It's in the best interests of OS vendors to get processors to work.
It's in the best interests of CPU vendors to get processors to work optimally on major platforms.
AMD's business is selling processors. Customers buy them if they perform better than the competitor's offers at the same price range. If your competitors optimizes implementations but you drop the ball and go with unoptimized ones, it matters nothing if your product performs better in theory if customers don't see that in the real world.
AMD has had heterogeneous cores since at least the beginning of the year with the 7900X3D and 7950X3D. The differences between cores there are even bigger than with these parts. Some cores clock lower but have more cache than others so depending on workload the optimal cores are different. With Zen4 vs Zen4c apparently only the clocks change so some cores are strictly better than the others.
Yes, that's true, AMD actually had such models since the 5X00 series. As I understand these models are somewhat niche and focused on the gaming market where AMD has some custom support for selecting the 3D cache cores.
Having said that, I don't really want to defend MS, they should add full support for this, but basically I believe it's just a matter of time.
I'm surprised that after 3 years since Intel's first big/little CPU (Lakefield), Windows still doesn't really support mixed cores. And that's over 10 years after the first ARM CPU with that kind of configuration. With their repeated attempts to get into the mobile space, you'd think they would've put more of an effort into this.
That simply seems untrue. Heterogeneous cores have existed since forever. SMT-aware has been a CPU feature in Windows for close to 2 decades, not to mention support for Intel's big-little designs
AMD's efficiency cores are much more similar to their mainline cores than for either Intel or ARM. Zen 4c cores have the exact same pattern of transistor connections as a regular Zen 4 core, it's just that the transistors much more of a consistently low width and so laid out differently, with those transistors that have to push signals long distances or to many consumers not allowed to grow as much. This means you can't drive the clock rates as high, but at the benefit of a smaller core and generally lower power usage.
> AMD's efficiency cores are much more similar to their mainline cores than for either Intel or ARM.
I apologize for going off on a tangent, but now that we have the benefit of hindsight what was the verdict on AMD's Bulldozer microarchitecture?
I recall that Intel invested a great deal on its anti-Bulldozer smear campaign with their "no true cores" accusations, but nowadays it seems that cheaper non-performance many-cores are the winning recipe.
> The problem of Bulldozer was that it only had slow cores.
I don't think that was the case. Bulldozer shared the FPU and cache, and if I recall correctly it was proven that the shared FPU was rarely a bottleneck because even in compute-intensive operations the number of FPU operations was relatively low.
That's not what I was hinting at. Bulldozer was slower than its predecessor Phenom in single-threaded tasks where shared FPU/cache shouldn't have a detrimental effect.
IIRC AMD made a trade-off to focus more on the multi-thread performance at the cost of single-thread performance (so basically more slower cores). But then many tasks are largely single-threaded and at that time the parallelization efforts were still very young.
Useful if (like for me) Anandtech's privacy choice pop up doesn't go away when you choose "REJECT ALL", instead just keeping in the middle of the screen forever.
Using the archive link, that pop-up doesn't appear at all.
29 comments
[ 3.4 ms ] story [ 62.6 ms ] thread> Unfortunately, however, because Windows sees all of the cores as identical, it also has no proper insight into energy efficiency here. Specifically, Windows has no idea that the Zen 4c cores are meant to be more energy efficient, so it will be making scheduling decisions based solely on workload/frequency metrics. This means that AMD is not able to take full advantage of the energy efficiency advantages offered by the Zen 4c CPU cores, as Windows isn't able to explicitly schedule threads on the more efficient cores. (An issue Intel gets around with their more meddlesome Thread Director)
Given that they are on feature parity with Zen 4, but trade higher clock speeds for density and efficiency - will we see the efficiency if Windows doesn't know any better?
Would Linux be able to do any better if it can tell the cores apart?
The official documentation is at https://www.kernel.org/doc/html/latest/scheduler/sched-energ... . I don't know if the kernel already has an energy model that can apply to the Zen4/Zen4c cores, probably the model/instrumention must be explicitly added.
If yes, is there any reason Windows can't receive a patch to be able to do so?
> is there any reason Windows can't receive a patch to be able to do so?
Probably not, given that Thread Director also runs on Windows AFAIK. AMD could probably cook up a solution if they needed one, but their E cores look pretty powerful from the get-go. My guess is that it won't need such a huge patch to perform well.
[0] https://www.tomshardware.com/news/intel-thread-director-comi...
"Windows 11 boosts performance of big.little x86 CPUs shows testing"
https://www.neowin.net/news/windows-11-boosts-performance-of...
"Microsoft and Intel confirm Windows 11 is optimized for Big.Little design"
https://www.neowin.net/news/microsoft-and-intel-confirm-wind...
AMD, from what I can tell, doesn't provide an equivalent to Intel Thread Director so Windows 11's scheduler has to work blind not unlike Windows 10's scheduler when working with Intel performance and efficiency cores.
So all else being equal, it's reasonable to assume Windows 11 will not take full advantage of AMD's performance and efficiency core architecture because the scheduler is working blind.
Isn't that simply because AMD so far didn't have any heterogenous cores and they will quite possibly/likely work with Windows to add support for them (just like Intel did)? It might take some time, but it seems needlessly pessimistic to expect that this won't happen in some form.
While there is certainly a need for some common scheduler logic, there also needs to be per-vendor or even per-model support added, since the OS first needs to even figure out which cores are which and each vendor's efficiency cores have different characteristics.
> Intel’s Thread Director controller puts an embedded microcontroller inside the processor such that it can monitor what each thread is doing and what it needs out of its performance metrics.
Linux literally has native support for heterogenous cores that works for both AMD and Intel. There's a world of difference between contributing to the kernel to ensure their CPU's work well and AMD being forced to put a microcontroller in their CPU and develop their own CPU-internal scheduling system.
I see Intel Thread Director quite similarly to how hardware manufacturers provide their own drivers. Sure, Microsoft could provide some generic driver, but that's not going to make full use of that hardware because only the manufacturer fully knows what's going on.
It's in the best interests of OS vendors to get processors to work.
It's in the best interests of CPU vendors to get processors to work optimally on major platforms.
AMD's business is selling processors. Customers buy them if they perform better than the competitor's offers at the same price range. If your competitors optimizes implementations but you drop the ball and go with unoptimized ones, it matters nothing if your product performs better in theory if customers don't see that in the real world.
Having said that, I don't really want to defend MS, they should add full support for this, but basically I believe it's just a matter of time.
It's AMD shot over the Apple line-up of laptops all at over 5 GHZ!
I apologize for going off on a tangent, but now that we have the benefit of hindsight what was the verdict on AMD's Bulldozer microarchitecture?
I recall that Intel invested a great deal on its anti-Bulldozer smear campaign with their "no true cores" accusations, but nowadays it seems that cheaper non-performance many-cores are the winning recipe.
https://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)
I don't think that was the case. Bulldozer shared the FPU and cache, and if I recall correctly it was proven that the shared FPU was rarely a bottleneck because even in compute-intensive operations the number of FPU operations was relatively low.
IIRC AMD made a trade-off to focus more on the multi-thread performance at the cost of single-thread performance (so basically more slower cores). But then many tasks are largely single-threaded and at that time the parallelization efforts were still very young.
Useful if (like for me) Anandtech's privacy choice pop up doesn't go away when you choose "REJECT ALL", instead just keeping in the middle of the screen forever.
Using the archive link, that pop-up doesn't appear at all.