[webkit-dev] Request for Position: Compute Pressure API

[Ryosuke Niwa]

On Thu, May 6, 2021 at 10:55 AM Olivier Yiptong <oyiptong at chromium.org>
wrote:
>
> Hi, and thank you for your prompt response. Replies inline.
>>
>>    1. CPU utilization isn't something which can be easily computed or
>>    reasoned on asymmetric multi-core CPUs, not to mention the dynamic
>>    adjustment of CPU frequency further complicates the matter.
>
>
> Are you alluding to CPU architectures like big.LITTLE? and of dynamic
clock frequencies?
>
> This proposal takes this into account, here's how:
>
...
>
> The goal of CPU Speed is to abstract away those details and provide clock
frequency data that is actionable and yet preserves user privacy.

The issue isn't that it's unclear to come up with some number that
represents the current CPU load. I'm sure we can come up with some number.
The issue lies in how such a number can be interpreted.

In our experience with iOS and macOS, CPU utilization & speed are poor
metric to use in order to adjust any software behavior because those things
are highly dynamic and respond quickly based on what an application is
doing. It's a lot better to *measure* the actual runtime taken to do a
specific task and adjust the behavior accordingly.

>>    2. Whether the system itself is under a heavy CPU load or not should
not
>>    have any bearing on how much CPU time a website is entitled to use
because
>>    the background CPU utilization may spontaneously change, and the
reason of
>>    a high or a low CPU utilization may depend on what the website is
doing;
>>    e.g. a daemon which wakes up in a response to a network request or
some
>>    file access.
>
> On the web, people write one-size-fits-all applications. Those need to
run across devices of varying compute power capabilities.
> For compute-intensive applications, this poses problems and leads to bad
UX in the absence of hints from the system.

This is precisely why we can't rely on CPU utilization or speed to
determine how fast the application or specific task thereof will complete.
There is a huge variability in each CPU's instructions per cycle, and how
much work can be performed in each cycle. The size of L1/L2/L3, cache
coherency mechanisms (with other cores potentially), prefetcher, the
capability and size of the branch predictor, etc... can all influence how
fast a given application will run. We can't estimate how fast an
application will run based purely on the percentage of CPU utilization or
at what fraction of the maximum frequency / power CPU is operating.

> The proposal does not enforce any additional usage of resources, but
instead allows apps to make informed decisions.
> It is common for compute-intensive applications to self-throttle to
provide a good UX.
> One example is gaming: reducing drawing distance, effects, texture sizes
or level of detail for geometries if it's affecting frame rate.

Those games are better off dynamically adjusting their behavior based on
how long each frame is taking to draw.

> On the Nintendo Switch, game engines have the feature to reduce the
rendering resolution when framerate drops occur or are anticipated.
> On the Nintendo Switch, the compute power capability depends on whether
the device is plugged in or in portable mode.
> There might also be thermal factors.

Here is the thing. On Apple's platforms, if an application adjusts itself
to do less work, then we'd start throttling CPU or stop using P-cores
automatically to conserve the battery so then you might drop frames because
CPU is running at a slower speed or no longer running in P-cores and takes
sometime to ramp up again. It is impractical for an application to respond
to these changes based on CPU utilization or speed information because the
states are changing so dynamically over time.

It's also highly inappropriate for a web app to assume that it can use all
the remaining CPU resources when there could be other windows and
applications the user is interacting with.

> For the Compute Pressure API, we've examined a few use-cases, and they
are detailed in the explainer.
> This is similar to video conferencing needs, reducing the number of
simultaneous video feeds, or diminishing the processing of image processing
effects.
>
> Indeed, the reason for the load might be intrinsic to the application, or
extrinsic, based on what's going on with the system.
> This API, as proposed, provides system-level hints that help applications
make informed decisions to provide a good UX for users.

We're very much uncomfortable with exposing this kind of invasive system
information in a Web API, and more importantly, web applications to adjust
its workload based on such information. JavaScriptCore's is a highly
sophisticated JIT engine that is known to perform very well across variety
of hardware classes and generations; yet it doesn't adjust its workload
based on CPU utilization or power state of the system. Given that, we are
highly skeptical with your premise that an API like this is needed to
create a performant application in the first place.

The explainer of this API mentions about not letting the device heat up.
This is a job of the user agent and the underlying operating system, not
individual of application, let alone websites and web apps. We're also
highly skeptical that this API will allow web apps to measure its power
impact of a new feature / behavior change. The power consumption depends on
a variety of things. For example, executing a task fast at 100% so that CPU
can go sleep quickly is often better than running at ~10% capacity for a
long period of time.

I can go on and on for many many paragraphs but I don't think it's
productive use of my time so I'd stop here. Please don't take the lack of
future response as an evidence of support or indifference unless we
explicitly say otherwise. We are and will be against this API unless
otherwise stated in a written form elsewhere.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210506/c4bbb0dd/attachment.htm>