I don't see what's the point of including hardware details into the W3C/HTML5/Javscript Specification.
And secondly, the demo said my old T7300 dual core would have 3 core.
And secondly, the demo said my old T7300 dual core would have 3 core.
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.
If you want to push for something, push for a mechanism that frees you from having to set the number of workers to spawn.
> 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...
As I see from others, the result reported by core-estimator is spot on N+1, where N is the number of virtual cores [2].
It might be a coincidence, but this is exactly the number of jobs one would give to make when compiling [3].
Knowing N helps to be efficient when spawning threads (avoiding swamping or starving cores).
[1] http://ark.intel.com/products/52229/ [2] as reported for example by /proc/cpuinfo on Linux [3] i.e. "make -j5"