[eboyjr]

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.

[ah-]

I don't think the number of cores is really useful for determining the number of web workers to run in parallel.

If you want to push for something, push for a mechanism that frees you from having to set the number of workers to spawn.

[eboyjr]

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...

[1gn1t10n]

That's exactly what a threading library abstraction aims to do. For example the Intel TBB (Threading Building Blocks).