[Webkit-unassigned] [Bug 132588] support for navigator.cores or navigator.hardwareConcurrency

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=132588





--- Comment #10 from Brady Eidson <beidson at apple.com>  2014-05-06 11:48:12 PST ---
(In reply to comment #7)
> (In reply to comment #4)
> > My turn to chime in.
> > 
> > - Reiterating the fingerprinting problem that's already been mentioned that we have no response to.
> 
> People on the blink team don't share this concern. I also don't see how valuable this information is, especially since it's easy to infer

Various security and privacy conscious groups have demonstrated just how much individuals can be uniquely identified by very few bits of info (and this is definitely a bit).  These groups are active in standards communities, such as W3C.  I've attended these face to face, and learned a lot about the fingerprinting problem from them.

It seems bizarre to me that the Blink team would discount what they've demonstrated.

Do they not care about the privacy aspect of "anonymous" tracking?
Or do they have evidence that what these groups have demonstrated is wrong?  Has this evidence been shared?

> > - "Number of physical cores" does not correlate to the number of simultaneous tasks supporter
> > - "Number of physical cores" does not correlate to computing resources currently available.
> 
> Does WebKit limit the number of Web Worker threads like gecko does, or does it launch as many as the author requests?
> If it limits the amount, that should be the number that this API returns.
> If not, this API should return the number of logical CPU instances.

In either case, this returns a static number that is almost always incorrect for the stated use cases of the API, because the number of workers *allowed* is not the same as the number cores *available*
> 
> > There modern approach to "let me do as much work as possible without hindering overall performance on the system" that at least some systems support.  Grand Central Dispatch on OS X, for example, will executed more tasks simultaneously when the resources are available but scale back when other apps demand some resources.
> > Is there a real problem that having this bit available would solve that couldn't also be solved by a GCD-style mechanism?
> 
> Even with a GCD-like solution, an author would often want to know how many threads can run at the same time so a task is not broken up in too many pieces or too many tasks are launched.

I'm not sure I can think of a case where a parallelizable task

> Desktop apps have been doing fine with just knowing the number of CPUs; 

They have?

The main reason GCD style mechanisms were brought into existence was because parallelization was seen as the future of improving system performance, with more and more processes and threads in flight at any given time on the machine.  Simply knowing the number of CPUs was no longer good enough to let everyone play nice.  Any one process is not in a position to know just how many resources are available at any time, nor is it in a position to adapt to rapidly changing system load.

While I have sympathy for hard core gamers who dedicate their entire machine to playing one game, or to scientific applications where the entire machine is dedicated to a single long running calculation, those are not the primary users of a modern machine.  Modern machines are expected to multitask well without the user realizing what's going on behind the scenes.

In a web environment, say you're running some scientific app in one tab, but also have a background tab open to an audio player and a 3rd tab with a casual game open.  Should all tabs suffer because the first is hogging everything?

>what makes the web platform different?

In most ways the web platform is not different, with my previous comment applying equally to it.

But, yes, the web platform *is* different in one important way - It is much newer and has less legacy than "the operating system", and therefore we can avoid some of the same mistakes.(In

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.