- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 6 May 2014 03:20:16 +0000 (UTC)
- To: Eli Grey <me@eligrey.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Kenneth Russell <kbr@google.com>, Joćo Carlos Martins Eiras <joaoe@opera.com>
On Mon, 5 May 2014, Eli Grey wrote: > > GCD exposes core count in that you can make your jobs keep track of the > current time and then count how many threads are running at the same > time. A GCD-style API will enable me to replace all of Core Estimator's > estimation and statistical code with a very simple counter and time > tracker, while yielding fully accurate core counts. > > I honestly cannot think of a system that doesn't make it possible to > derive core count even easier than I currently can. You are assuming that the system is not under load. This is a false assumption. (Your current core estimator makes the same mistake, as I and others have pointer out several times.) You're also assuming there's no potentially-variable per-origin thread limit, etc, which is also a false assumption (q.v. Gecko's implementation of Workers today, as bz pointed out earlier). Indeed, on a high-core machine as we should expect to start seeing widely in the coming years, it might make sense for the browser to randomly limit the number of cores on a per-origin/session basis, specifically to mitigate fingerprinting. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 6 May 2014 03:20:40 UTC