> 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.
In a way that can't wait tens of microseconds?
> and he'll be stuck spending a lot of time figuring out how to pin that process to that core.
Pinning to cores is really easy.
> Worker drone me is going to be sad thinking that slack and chrome are snarfing the good cores while my compile times suffer.
I'd say something about adjusting priorities but there's a much more important thing to realize here.
If your CPU didn't have this, you'd have 6 fewer cores. Or probably 12 in the next version. Even if your compiler can't use two of the fast cores, it's going to run much faster overall.
> tragedy of the commons situation
If you want to improve your own responsiveness at the expense of other programs you could already busy loop everything. And nobody does that.
For years, there were multiple Android SoCs with stupid amounts of cores, a mixup between 2 or 3 core types, and the end result is that pretty much all contemporary matchups between the best and worst Apple SoCs and ARM SoCs put in Android phones were favoring the glorious fruit company.
I'm curious if the existing cpu performance of even mid-range modern phone SoCs is really even used by most users. I suspect gamering and winning benchmarks may be the primary use cases.
I was trying to reduce power consumption on my phone, and disabled all but one low perf core (the phone's SoC has 2 high perf and 4 low perf cores), and things were very noticeably laggy.
But, then, I tried with only two low perf cores enabled. Everything that I used my phone for (calls, messaging, notes, web browsing with an ad blocker) worked fine. So, the extra four disabled cores really didn't affect my ?average? use case.
I was concerned about consumption during active usage, not idle, but disabling the cores didn't affect power consumption for either (even with only one enabled).
It is a Qualcomm Snapdragon 765G. I assumed there would be aggressive power gating for a mobile processor, but I have no idea. Google didn't turn up anything. Maybe in some doc behind an NDA?
I’m still unconvinced about Intels big core little core architecture. Sounds great for a laptop, but I don’t want that in my desktop. In games waiting tens of milliseconds is a long time.
It can advise on shifting cores around as fast as the OS is ready to, so the delay doesn't have to be worse than a normal sleep.
If you have a normal "active game" timer frequency, then Windows is probably checking in every millisecond, and it will have extremely accurate data to use. And that's even without any special mechanisms to react faster.
In a way that can't wait tens of microseconds?
> and he'll be stuck spending a lot of time figuring out how to pin that process to that core.
Pinning to cores is really easy.
> Worker drone me is going to be sad thinking that slack and chrome are snarfing the good cores while my compile times suffer.
I'd say something about adjusting priorities but there's a much more important thing to realize here.
If your CPU didn't have this, you'd have 6 fewer cores. Or probably 12 in the next version. Even if your compiler can't use two of the fast cores, it's going to run much faster overall.
> tragedy of the commons situation
If you want to improve your own responsiveness at the expense of other programs you could already busy loop everything. And nobody does that.
I don't think it's something to worry about.