Hobbyist me thinks this is really cool. Thinking about how different runtimes might hint allocation of resources is fascinating.<p>Professional me knows I'll be stuck figuring out that some bursty process that really needs p1 access all the time, in spite of usually being idle is going to be super pissed off when he gets paged at 2am. and he'll be stuck spending a lot of time figuring out how to pin that process to that core.<p>Worker drone me is going to be sad thinking that slack and chrome are snarfing the good cores while my compile times suffer.<p>Bit of a hot take, but it's a tragedy of the commons situation. Programmers are smart, they'll find tricks to grab the fast cores. There are a maybe zero organizations that can get alignment to keep important processes on fast cores, it's way better to just be fast and point the finger at other teams for being slow. What a time to be alive.<p>It's super cool. it has potential to be amazing. But even forcing every task to run on an E-core, and a heavy bias to fast cores being idle will be gamed. I guess it's better to know than be surprised.
My big question is how will hypervisors handle this heterogenous architecture, and how much it will affect them. All cores are not equal which means vCPUs are no longer just vCPUs. I believe most guest workloads are somewhat opaque to the hypervisor, and as far as I know there isn't yet a way for guests to be aware of or demand on what cores its workloads are scheduled on any of the major hypervisors.
Didn't Intel already try something like this with Lakefield? It didn't go well.<p>Let's say the thread starts on a high performance core and enables the code paths for features the efficiency core doesn't have. How will the software know to not move the thread to the efficiency core? If it did do so wouldn't it throw errors? I frankly don't see how they can solve this problem with software and not have to recompile everything to be hybrid arch aware. In the android space everyone throws their phones away every few years so this hasn't been an issue. To me it seems like Intel is creating another Itanic situation where no one is going to compile their software to target the hybrid paradigm.
> This fundamental change is one reason why Windows 11 exists.<p>they couldn't change the thread scheduler without a new major release?<p>pull the other one
It doesn’t sound like anyone outside of Intel and Microsoft actually knows how this works. How are Linux and the BSDs going to be able to support this?
I'm surprised they prioritized Windows 11 and not Linux. Is this meant to most benefit consumers? I'd think something so complex would have been first targeted at servers.
From the article “In previous versions of Windows, the scheduler had to rely on analysing the programs on its own, inferring performance requirements of a thread but with no real underlying understanding of what was happening.”<p>Does anyone know what is meant by the scheduler analyses the program?