Proposal: revisit and implement navigator.hardwareConcurrency

[Luke Wagner]

Since the original m.d.p thread on hardwareConcurrency last year:
https://groups.google.com/d/topic/mozilla.dev.platform/QnhfUVw9jCI/discussion
the landscape has shifted (as always) and I think we should reevaluate
and implement this feature.

What hasn't changed are the arguments, made in the original thread,
that hardwareConcurrency is a clumsy way to decide how many workers to
create and can lead to the creation of too many workers in various
scenarios (e.g., multiple tabs all attempting to saturate all the cores,
cores vs. hyperthreads).

What has changed is the appearance of more compelling use cases. In
particular, the upcoming support for SharedArrayBuffer [1][2] allows
Emscripten to compile pthreads [3] applications, which has been the #1
compile-to-web feature request over the last few years. Specifically, native
game engines find the number of logical cores on the machine (using APIs
present in C++11, etc.), and use a number of threads based on that (often
adjusted, and they have a lot of experience tuning this). They would like to
do the same on the web, and Chrome and Safari already let them. In the
absence of hardwareConcurrency, developers are forced to resort to either
hardcoding a constant number of workers or using a polyfill library [4] that
estimates the number of cores. Unfortunately, the polyfill takes a few
seconds (hurting startup time) and produces inaccurate results (based on
evaluations from multiple parties) [5]. Thus, while hardwareConcurrency
isn't ideal, it's strictly better than what developers have now in Firefox.

Moreover, I don't think the applicability of hardwareConcurrency is
limited to compile-to-web uses. I think all the use cases we're
seeing now from compiled native apps will manifest in JS apps further
down the line as worker usage becomes more commonplace and
applications grow more demanding. As in many other cases, I think
games are serving as a catalyst here, proving what's possible and
paving the way for fleets of non-game applications.

But will the existence of hardwareConcurrency encourage bad behavior
in every-day web browsing? I don't think so. First of all,
hardwareConcurrency is meant to help good actors who want to
ensure a good experience for their users. Bad actors can already
saturate all your cores with Workers. Thus, as Worker (mis)use
becomes more widespread on the Web, it seems inevitable we'll need
to do some form of Worker throttling (via thread priority or
SuspendThread/pthread_kill) of background/invisible windows *anyway*;
it seems like the only reason we haven't had to do this already is
because Workers just aren't used that much in normal web apps. For
good actors, though, it is possible to mitigate some of the clumsiness
of hardwareConcurrency: using SharedWorkers to detect the "same
app open in many tabs" case; using the PageVisibility API to pause
work when not visible (which will likely happen anyway in frame-driven
applications based on requestAnimationFrame throttling of background
tabs). Lastly, for neither good nor bad actors, I think the hazard of
casual/widespread use is more limited by the hurdles of using workers
at all (w/ or w/o SharedArrayBuffer).

Will we get stuck with hardwareConcurrency forever? I don't think
so. Farther down the line, as more web apps take advantage of workers
and we find real examples of CPU contention for which throttling
mitigations aren't sufficient, we will be motivated to improve and
propose a more responsive API. However, I don't think we can design
that API now: we don't have the use cases to evaluate the API against.
This is the basic Web evolutionary strategy.

On the subject of fingerprinting: as stated above, core count can
already be roughly measured [4]. While the extra precision and speed
of hardwareConcurrency does make fingerprinting somewhat easier, as
we've done with other features, we need to weigh the value to users
against information revealed. In this case, it seems like the ratio
is pretty heavily weighted toward the value.

On a more technical detail: WebKit and Chromium have both shipped,
returning the number of logical processors where WebKit additionally
clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
by WHATWG text [7]. I would argue for not clamping (like Chrome),
although I do think we'll have a good amount of flexibility to change
clamping over time based on experience.

How does that sound?

Cheers,
Luke

[1] https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/
[2] https://github.com/lars-t-hansen/ecmascript_sharedmem
[3] https://groups.google.com/forum/#!msg/emscripten-discuss/gQQRjajQ6iY/DcYQpQyPQmIJ
[4] http://wg.oftn.org/projects/core-estimator/demo/
[5] https://bugs.webkit.org/show_bug.cgi?id=132588#c86
[6] https://trac.webkit.org/browser/trunk/Source/WebCore/page/Navigator.cpp#L137
[7] https://wiki.whatwg.org/wiki/Navigator_HW_Concurrency

[Jonas Sicking]

I'm ok with implementing this. My biggest concern has always been
fingerprinting, and I think that we'll need some way to deal with
active (i.e. client-side) fingerprinting anyway, so I don't think this
makes a big difference either way.

/ Jonas

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Robert O'Callahan]

Yes, I think we should do this.

Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

[Rik Cabanier]

On Tue, Sep 8, 2015 at 2:14 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> Yes, I think we should do this.
>

Happy to hear the positive responses.
I implemented a patch for this last year. Since the code is trivial, it
probably still applies: https://bugzilla.mozilla.org/show_bug.cgi?id=1008453

[Ben Kelly]

FWIW, I also think we should implement this. The clamping seems like a
reasonable way to be conservative given the fingerprinting concerns.

[Johnny Stenback]

While deciding how much resources are available to complex
applications is far from an easy task, and one for which there's no
obvious best answer, at least not yet, I agree that giving developers
this bit of information is critical to enable exploring this space and
bring out the any remaining issues I too think we should do this.
Thanks for writing this up Luke!

- jst

[Anne van Kesteren]

On Tue, Sep 8, 2015 at 9:21 PM, Luke Wagner <lwa...@mozilla.com> wrote:
> https://wiki.whatwg.org/wiki/Navigator_HW_Concurrency

Anyone here interested in making a PR against
https://github.com/whatwg/html so the actual standard is updated too?


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 9/8/15 3:21 PM, Luke Wagner wrote:
> On a more technical detail: WebKit and Chromium have both shipped,
> returning the number of logical processors where WebKit additionally
> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
> by WHATWG text [7]. I would argue for not clamping (like Chrome),

Given the use cases, should we clamp to our per-origin limit?

-Boris

[Mats Palmgren]

> On 9/8/15 3:21 PM, Luke Wagner wrote:
>> On a more technical detail: WebKit and Chromium have both shipped,
>> returning the number of logical processors where WebKit additionally
>> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
>> by WHATWG text [7]. I would argue for not clamping (like Chrome),

If that clamping is good enough for WebKit then why shouldn't it
work for our users too?

/Mats

[Ehsan Akhgari]

I brought this up in an in person meeting about this a while ago. It
seems pretty hard to justify returning a number more than our per-origin
worker limit. To be clear, this will be a clamping different to what
WebKit does.

[Kyle Huey]

On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On 2016-03-14 3:23 PM, Boris Zbarsky wrote:

> I brought this up in an in person meeting about this a while ago. It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit. To be clear, this will be a clamping different to what
> WebKit does.
>

That number is 20 or 50 or something like that though.

- Kyle

[Boris Zbarsky]

On 3/14/16 5:30 PM, Ehsan Akhgari wrote:
> I brought this up in an in person meeting about this a while ago. It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit. To be clear, this will be a clamping different to what
> WebKit does.

OK. So my current plan is to implement this, clamp to the max workers
per domain number, but do no other clamping. Failures of various kinds
in the API will just cause it to return 1. I guess I'll send and intent
to ship.

I'm not sure there's an actual spec for this other than
https://wiki.whatwg.org/wiki/NavigatorCores though...

-Boris

[Ehsan Akhgari]

On 2016-03-14 6:43 PM, Kyle Huey wrote:
> On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2016-03-14 3:23 PM, Boris Zbarsky wrote:

> I brought this up in an in person meeting about this a while ago. It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit. To be clear, this will be a clamping different to what
> WebKit does.
>
>

> That number is 20 or 50 or something like that though.

Ah yeah, we bumped it up to 50 in bug 1241485, so I guess the clamping
won't matter for most machines that people use these days.