Hacker News Reader

Desktop GUIs are really lagging when it comes to giving the user tools to corral unruly apps. I know, they were born in a more trusting time, but mobile has understood for many years that the user-app relationship can get slightly adversarial. It's high time for the desktop to take a more solid swing at it.

Hey, maybe we could even have kept Flash around if it were easy to prevent flash ads from fighting each other to take 100% CPU. It might have taken some iteration to figure out how to map a simple GUI-appropriate slider to a scheduling policy (10% -> 10ms every 100ms?) but I bet it could have been done. It would have had a nice side effect of appropriately directing user outrage at offending applications, too.

Browsers should support resource quotas.

I wouldn't mind the client side scripts so much if they behaved. Even with uBlock and such, random pages will peg my CPU, drain my battery. IIRC, allrecipes.com, imdb.com, and of course youtube.com.

Forcing Reader View often helps, but it's hit & miss.

The Great Suspender worked ok for Chrome. But I'm now 90% Safari and 10% FireFox.

Adjacent Idea: Browser history should also include other meta. Like page size. (weight), resources consumed, time spent on page, when page was closed, permissions requested & granted, etc.

> 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.

I don't think it's something to worry about.

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.

Underappreciated fact - the Apple SoCs since A10 (iPhone 7, etc) are also big.LITTLE designs! https://en.m.wikipedia.org/wiki/Apple_A10

You're correct, I was not aware of this. You've invalidated my argument and I stand corrected.

And Macs are now big.LITTLE as well. I’m curious how this compares to what apple does for macOS.

A10 was kind of a strange big.LITTLE in that it could only run one set at a time. Future revisions fixed this.

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).

Is the SoC in question even capable of physically powering down individual cores?

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.

For a desktop (or a laptop plugged in) you could just use little cores for sleep mode.

Or let the little cores run OS processes that are always running so they don't interrupt your game.

micro seconds.

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.

How? This just gives more control to the OS. It's the OS's job to ensure that process priorities are enforced. I don't see how you get around that.

my (flawed?) impression is, the OS implementation is heuristic. putting a process on a core is not much different than putting state in swap. it's not that important with nvram disks, but it's not that hard to keep your data out of swap. There's bound to be a way to keep a process on the fast core. Just do some useless work that keeps the process on the fast core. Or cooperate with the os to keep the critical process on the fast core.

I don't know. I don't really spend a lot of time dealing with gamed process priority. Would this be all that different?