Hacker News Reader

Comment by LiamPowell | Hacker News Reader

The problem with exposing an API for this is that far too many developers will force the highest performance state all the time. I don't know if there's really a good way to stop that and have the API at the same time.

View on HN

There already is an unending number of ways for just one app to waste charge on battery-powered devices. It all already relies on developers not unnecessarily running energy-intensive tasks, either intentionally or accidentally. Adding one more API that has the potential to waste energy if not used appropriately will not change that.

macOS also has a bunch of mechanisms to inform the user about this! IIRC the battery menu has entries for apps draining a lot of power (iterm always shows up there for me!)

My potentially incorrect understanding is that iTerm generally only shows up when the processes you run inside it are consuming a bunch of energy. It only shows up in the battery menu for me when I’m running simulations or other big CPU intensive stuff on the command line.

Yeah - I've always thought about this and was never sure!

The article mentions game mode, which is a feature of the latest Apple operating systems that is optimised for cases like this. Game mode pops up a notification when it’s enabled, which most applications wouldn’t want to happen. So far I haven’t seen anything abuse it.

Requiring a fullscreen window stops almost all possible abuses, though, as you cannot do this from a background process.

Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio workgroup is issuing commands to the GPU there should be some kind of timeout to the GPU downclocking based on the last time a workgroup sent data to it.

GPU audio is extremely niche these days, but with the company mentioned in TFA releasing their SDK recently it may become more popular. Although I don't buy it because if you're doing thing on GPU you're saying you don't care about latency, so bump your i/o buffer sizes.

I'm not too familiar with audio workgroups but since the early days XNU had low-level APIs to set pthreads as pseudo-realtime

This will definitely get you to run with a higher priority than the user's time machine backup, but it's not guaranteed to get your code onto a p-core if the machine is on battery and your app doesn't have focus.

> if you're doing thing on GPU you're saying you don't care about latency

This does not follow. Evidently it is possible to have low-latency audio processing on the GPU today (per the SDK).

Abusing the API would still be more efficient than running fake busy workloads to do the same, which apps can already fo without the API (or permissions the API could require).

Manual permission? Maybe hidden somewhere, it's probably necessary for very niche apps.

And default deny at the OS level for Zoom, Teams and web browsers :)

But as the author mentions, they already do it by having a process spin indefinitely. If they want to abuse it, they will and can already.

It's better to trust, the amount of people that won't abuse it far outweigh the ones that do.

Reply on news.ycombinator.com