[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 #11 from Brady Eidson <beidson at apple.com>  2014-05-06 11:59:58 PST ---
(In reply to comment #5)
> (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.
> > - "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.
> > 
> 
> I believe that they want the equivalent of hw.availcpu which isn't what either of your bullets tell you. 

If it is meant to adapt to dynamically changing system load, is there a notification API to tell the page when the value has changed?

Because I doubt we'd want an API that requires polling.

Also, this is not what Rik suggested it is...  I definitely agree that we're discussing an unspec'ed feature!  :)

> > 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?
> 
> Yes. Absolutely. Numerical parallel algorithms are often written in a worker-per-CPU style and this ends up being faster than the mini-task model of GCD. 

I'm not up to date with start of the art numerical parallel algorithms, so I'll definitely believe that this is how they are often written.

But are you actually saying that they cannot *possibly* be written with a mini-task model to perform almost as well?

Here's what I'm imagining.  It's simple and possibly quite naive, but it seems right to me.
An algorithm that wants to run 8 threads for 10 seconds each.
Scenario 1 - In the "I know I have 8 CPU cores" model, it spawns those 8 threads
Scenario 2 - In the "GCD mini task" scenario it queues up 8 tasks that might take ~1/4 second to complete, and when one completes it kicks off the next one.

In a perfectly ideal world of zero system load:
Scenario 1 spreads 80 seconds of work over 8 threads, and finishes in 80 seconds.
Scenario 2 spreads 80 seconds of work over 320 mini tasks, and finishes in 80 seconds + some GCD overhead time.

In a real world where the user is actively using their system:
Scenario 1 spreads 80 seconds of work over 8 threads, finishes in (possibly much) more than 80 seconds, and causes the system to be sluggish to the user in the meantime.
Scenario 2 spreads 80 seconds of work over 320 mini tasks, finishes in (possible much) more than 80 seconds, but the system remains perfectly responsive to the user in the meantime.

While 8 threads is the winner in the zero-load case, it's only the winner by a small amount.
The mini-task model is the clear winner in the "system is being used" case, with a significant advantage.

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