Re: [whatwg] Proposal: navigator.cores

I have a list of example use cases at
http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases

Each of these use cases involves a parallelizable algorithm that needs
to run as fast as possible on the user's system in order for the user
to have a responsive experience. You can never run any of these
algorithms "too" fast/with "too many" resources. It's all part of the
race to sleep/idle.

Thread priority does not increase performance of these algorithms
nearly as dramatically as using more threads when there are more
available processors to run threads on. Currently you would use 1
thread for all of these use cases, even if the user has 4 cores,
simply because you do not know how many cores the user has.

Also, allowing webapps to set thread priority is very dangerous and
can cause system lockup.

On Mon, May 5, 2014 at 7:09 PM, João Carlos Martins Eiras
<joaoe@opera.com> wrote:
> Hi.
>
> I'm just taking a peek at this topic. My first impression is: why
> would anyone want such a low level hardware information (CPU cores and
> whatnot) on something as high level and abstract as a browser? This
> strikes me initially a useful as having the CPU architecture exposed
> as well.
>
> However, I do see the use cases of somehow being more forgiving with
> CPU usage. But this would be much better achieved with an API like
> defining the priority of workers (high, normal, low) and other async
> tasks, and let the user agent do all the resource allocation and
> management, because that's what user agents are built to do. In any
> case the user agent would make those choices better than the web
> developer.
>
> The only use case I can think of where a web page might want explicit
> hardware information is for driver download pages, benchmarks or
> collecting statistics. But these cases would be better solved with a
> specialized API requiring user consent.

Received on Monday, 5 May 2014 23:32:00 UTC