eboyjr

In practice, when people use our library, we recommend that the test is called only when it's needed, instead of directly when the page loads. There are also other guidelines as well such as always allowing the user the manually edit the number of cores used in an app.

I'd be interested to know who is getting very close to accurate results on their machines. (Being off by 1 or 2 is not a big deal since CPU availability is more important to a developer than the number of CPU cores)

ernesth and I have the same problem on Opera. I'm looking into why that is.

Weird. Core Estimator performs very strangely on Opera, we're trying to find out why.

I did find this interesting piece of information.

> In a compute-bound application running on an N-processor machine, adding additional threads may improve throughput as the number of threads approaches N, but adding additional threads beyond N will do no good. Indeed, too many threads will even degrade performance because of the additional context switching overhead. The optimum size of a thread pool depends on the number of processors available and the nature of the tasks on the work queue. On an N-processor system for a work queue that will hold entirely compute-bound tasks, you will generally achieve maximum CPU utilization with a thread pool of N or N+1 threads.

From http://www.ibm.com/developerworks/library/j-jtp0730/index.ht...

Thanks for the results it really helps us. We have a lot more planned to improve Core Estimator's accuracy coming up.

If you read the blog you would know why this information is useful :)

Web workers make it possible to do parallel computation with JavaScript, and knowing the right number to spawn helps to make sure resources are being taken advantage of. We already have the ability to run JavaScript code on multiple processors, but currently, you can't tell where it's being run. For performance reasons, knowing the number of workers to spawn can make a big difference.

Secondly, it's called an estimator so it's never going to be perfect. It's a tool designed to give you some idea of what is going on.

On some machines it is likely that the result you get the second time will be different from the first.

And you're right, we designed the script to find the optimum number of web workers to use in parallel, that's what it's primary purpose is. But we also want to drive adoption of navigator.cores so we decided to call it a core estimator.

Yeah. There are a lot of outside influences that can affect the results of the estimation. Unfortunately this is the only way to go until browsers vendors adopt navigator.cores. Future versions will be able to cope better with this by taking advantage of localStorage on the user's machine and averaging it out.

lol