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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
