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 On Tue, Sep 8, 2015 at 2:22 PM, Ben Kelly <bke...@mozilla.com> wrote: > FWIW, I also think we should implement this. The clamping seems like a > reasonable way to be conservative given the fingerprinting concerns. > > On Tue, Sep 8, 2015 at 3:21 PM, Luke Wagner <lwag...@mozilla.com> wrote: > >> 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 >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
