Hacker News new | ask | show | jobs
by ekr 4773 days ago
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.

2 comments

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.

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.

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

That's exactly what a threading library abstraction aims to do. For example the Intel TBB (Threading Building Blocks).
On an Intel i5-2520M (4 threads [1]) it reported 5 usable worker threads.

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"