3 ms·

OS could make Hyper threading opt-in per application thread. So chrome could mark its render threads as HT-groupable and they can share a core between them, but

OS could make Hyper threading opt-in per application thread. So chrome could mark its render threads as HT-groupable and they can share a core between them, but otherwise cores are not shared. There might be different levels of thread opt-in, prime95 might not care about other threads finding out what the 338134th digit of prime is and mark its threads as unrestricted sharable.

illumin8 8y ago
This is the right approach, IMHO. Let me run local apps like video rendering and transcoding using all cores, but let me mark anything that has Internet access as only executing on a dedicated core. Apple's new hardware approach might work well for this: on the A12X chip used by the new iPad Pro, they have 4 high performance cores and 4 low power cores. Let Chrome have a couple low power cores, and that solves a few problems: 1. I get security isolation between Chrome and the rest of my apps. 2. I no longer care very much when poorly written javascript wants to consume 100% of CPU because it's only running on a low power core. 3. My battery life is also better because Chrome can't consume a high power core.
- zrm 8y ago
  It should be possible to do the same thing on anything that supports CPU frequency scaling. Tell the OS that the core the browser is running on should only run at the lowest supported frequency. Or only allow it to run at higher frequency if it hasn't been active for more than 15 of the last 60 seconds.
- amaccuish 8y ago
  FYI Apple didn't come up with the idea of having differing cores: https://en.wikipedia.org/wiki/ARM_big.LITTLE https://en.wikipedia.org/wiki/ARM_big.LITTLE
  - deleted 8y ago
    [deleted]
gravypod 8y ago
Unfortunately this contention is the exact reason this isn't done. Similar workloads (from the same program) will perform poorly in the same SMT groups. You can try this in windows using the core affinity of processes. You'll find that when one application shares both HTs it will perform much worse.
- zrav 8y ago
  Under optimal conditions (rendering) enabling SMT on Intel gives just ~30% extra performance, ~40% on AMD (usually much less), so of course you can't compare the additional thread provided by SMT to a thread running on another, otherwise idle core. Scheduling only threads of the same process on a SMT group at a time is the easiest portsmash mitigation while still retaining some of the SMT peformance benefit.

illumin8 8y ago

This is the right approach, IMHO. Let me run local apps like video rendering and transcoding using all cores, but let me mark anything that has Internet access as only executing on a dedicated core. Apple's new hardware approach might work well for this: on the A12X chip used by the new iPad Pro, they have 4 high performance cores and 4 low power cores. Let Chrome have a couple low power cores, and that solves a few problems: 1. I get security isolation between Chrome and the rest of my apps. 2. I no longer care very much when poorly written javascript wants to consume 100% of CPU because it's only running on a low power core. 3. My battery life is also better because Chrome can't consume a high power core.

zrm 8y ago
It should be possible to do the same thing on anything that supports CPU frequency scaling. Tell the OS that the core the browser is running on should only run at the lowest supported frequency. Or only allow it to run at higher frequency if it hasn't been active for more than 15 of the last 60 seconds.
amaccuish 8y ago
FYI Apple didn't come up with the idea of having differing cores: https://en.wikipedia.org/wiki/ARM_big.LITTLE https://en.wikipedia.org/wiki/ARM_big.LITTLE
- deleted 8y ago
  [deleted]

gravypod 8y ago

Unfortunately this contention is the exact reason this isn't done. Similar workloads (from the same program) will perform poorly in the same SMT groups. You can try this in windows using the core affinity of processes. You'll find that when one application shares both HTs it will perform much worse.

zrav 8y ago
Under optimal conditions (rendering) enabling SMT on Intel gives just ~30% extra performance, ~40% on AMD (usually much less), so of course you can't compare the additional thread provided by SMT to a thread running on another, otherwise idle core. Scheduling only threads of the same process on a SMT group at a time is the easiest portsmash mitigation while still retaining some of the SMT peformance benefit.