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 On Tue, Sep 8, 2015 at 12: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
