[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

Wed May 7 19:15:25 PDT 2014

Naive question(s) here.

Why does the physical number of cores ( and that is not necessarily the number of actionable native threads ) matter?

I would expect a mature system to do the best it can with hardware, in what the software has asked for it. Some tasks are sleepy, some are IO bound, some CPU - this is the job of the host kernel to cope.

Whilst I can accept that there are some tasks for which you  may want to craft your number of workers for to get the best CPU/GPU through put - this sounds to be to be in the realm of something for which you probably shouldn’t be coding in javascript inside a web browser for.

( I’m also not immune to concern about security re: fingerprinting - but then, how much information do you really get from that? Given the propensity to use virtual machines / cloud - the number of “processors” is pretty mutable ).

Personally, I like to control CPU usage - I’m happy restricting my browser to 2 cores - so the others are free for other tasks as a developer - you can’t ask an uninformed user to handle cpu binding - so relying on the host OS to “do the best it can” and assuming you have say 1..4 “cores” in an app should work.

Anything else is high-performance computing. I’m not convinced that a web-browser is the place to worry about that.

I’m also leary of anything not standards based - so perhaps *somebody* should push for a standard whereby you can ask the host os ‘ how many threads can you handle right now?” - which may or may not be number of cores - depending on system load.

Steve "Harry" Coul
scoul at cisco.com<mailto:scoul at cisco.com>

On May 7, 2014, at 7:38 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>> wrote:

On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain <benjamin at webkit.org<mailto:benjamin at webkit.org>> wrote:
On 5/7/14, 4:13 PM, Benjamin Poulain wrote:
On 5/7/14, 3:52 PM, Filip Pizlo wrote:
Exactly. Ben, Oliver, and others have made arguments against web
workers. Rik is not proposing web workers.  We already support them. The
point is to give API to let developers opt into behaving nicely if they
are already using web workers.

I have nothing against Web Workers. They are useful to dispatch
background tasks.

They are basically the Web equivalent dispatch_async() of GCD, which is
already a very useful tool.

What you are suggesting is useful for making Web Workers the tool to do
high performance multi-thread computation.
I don't think Web Workers are a great tool for that job at the moment. I
would prefer something along TBB, GCD or something like that.

For high performance computation, I think a more useful API would be
something like TBB parallel_for with automatic chunking.
It is actually had to do faster than that with the number of cores
unless you know your task very very well.

It would be a little more work for us, but a huge convenience for the
users of Web Workers.

After chatting with Filip, it seems such a model is unlikely to happen anytime soon for JavaScript.

In the absence of any tasks/kernels model, I am in favor of exposing a "good number of thread" API. It is definitely better than nothing.

Do we know what this number would be? My guess would be the number of cores for "regular" systems...
Boris Zbarsky indicated that Firefox figures out how many workers should run concurrently. Maybe we can reuse that algorithm?

They can already write code that overloads the system but they currently
have *no* way of writing code that even tries to be well-behaved except
maybe to avoid workers entirely.

I'm also a little disturbed by arguments against the general usefulness
of ncpu. We use it for the parallel JIT and parallel GC because
regardless of system load those are *the best* guesses of how many cpus
to use.

-Fil

On May 7, 2014, at 3:24 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>
<mailto:cabanier at gmail.com<mailto:cabanier at gmail.com>>> wrote:

On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <oliver at apple.com<mailto:oliver at apple.com>
<mailto:oliver at apple.com<mailto:oliver at apple.com>>> wrote:

    On May 7, 2014, at 3:15 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>
    <mailto:cabanier at gmail.com<mailto:cabanier at gmail.com>>> wrote:

    On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <oliver at apple.com<mailto:oliver at apple.com>
    <mailto:oliver at apple.com<mailto:oliver at apple.com>>> wrote:

        On May 7, 2014, at 2:41 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>
        <mailto:cabanier at gmail.com<mailto:cabanier at gmail.com>>> wrote:
        >
        > When would I as a user, not want a page or web application
        to be as fast as possible? Has a user ever complained about a
        desktop app that uses too many of his CPU's? I think Oliver's
        point was that other processes might fight for the same CPU
        resources but that is not unexpected for users.

        What happen if i go to your website while i'm doing something
        else in the background?  What if i'm playing a game while
        waiting for my machine to do something else? What if your
        page is in the background? Or my battery is running low.

    Sure. However, a page can already do this today.
    This will just give the author a way to make a semi-informed
    decision. Without this, he might just spin up too many threads
    and starve the rest of the system.

        You need to stop thinking in terms of a user wanting only one
        thing to happen at a time.

    I'm not sure if I follow. How would this be any different from a
    regular desktop application?

    The argument is that this is not behaviour that users want - the
    fact that desktop applications do this is a bug in the programming
    model.

    APIs like GCD were specifically created to allow a developer to
    make an application than can automatically scale (or descale) to
    match the behaviour that is best for the user. That’s the model we
    want to encourage on the web.

Filip already covered this much better than I could in the webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=132588

This proposal is not about inventing a thread/task scheduling
mechanism; this is just a way to make an informed guess without having
to use a polyfill,
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org> <mailto:webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>>
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140508/11e183ae/attachment.html>