W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: navigator.cores

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 6 May 2014 03:20:16 +0000 (UTC)
To: Eli Grey <me@eligrey.com>
Message-ID: <alpine.DEB.2.00.1405060314220.11724@ps20323.dreamhostps.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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC