5 ms·

Hobbyist me thinks this is really cool. Thinking about how different runtimes might hint allocation of resources is fascinating. Professional me knows I'll be

by jfoutz 5y ago

Hobbyist me thinks this is really cool. Thinking about how different runtimes might hint allocation of resources is fascinating. 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. Worker drone me is going to be sad thinking that slack and chrome are snarfing the good cores while my compile times suffer. 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. 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.

omegalulw 5y ago
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.
- jfoutz 5y ago
  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.
  - deleted 5y ago
    [deleted]
Dylan16807 5y ago
> 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.
- eptcyka 5y ago
  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.
  - ajtulloch 5y ago
    Underappreciated fact - the Apple SoCs since A10 (iPhone 7, etc) are also big.LITTLE designs! https://en.m.wikipedia.org/wiki/Apple_A10 https://en.m.wikipedia.org/wiki/Apple_A10
    - eptcyka 5y ago
      You're correct, I was not aware of this. You've invalidated my argument and I stand corrected.
      - sroussey 5y ago
        And Macs are now big.LITTLE as well. I’m curious how this compares to what apple does for macOS.
jjoonathan 5y ago
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.
- deleted 5y ago
  [deleted]
- specialist 5y ago
  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.
jayd16 5y ago
I don't know. I don't really spend a lot of time dealing with gamed process priority. Would this be all that different?

by jfoutz 5y ago

omegalulw 5y ago

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.

jfoutz 5y ago
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.
- deleted 5y ago
  [deleted]

Dylan16807 5y ago

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

eptcyka 5y ago
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.
- ajtulloch 5y ago
  Underappreciated fact - the Apple SoCs since A10 (iPhone 7, etc) are also big.LITTLE designs! https://en.m.wikipedia.org/wiki/Apple_A10 https://en.m.wikipedia.org/wiki/Apple_A10
  - eptcyka 5y ago
    You're correct, I was not aware of this. You've invalidated my argument and I stand corrected.
    - sroussey 5y ago
      And Macs are now big.LITTLE as well. I’m curious how this compares to what apple does for macOS.

jjoonathan 5y ago

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.

deleted 5y ago
[deleted]
specialist 5y ago
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.

jayd16 5y ago

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