On 5/20/2014 12:46 PM, Eli Grey wrote:
Your worker threadpool will always stay the same size, but it will have
different performance characteristics throughout it's lifetime based on
varying system load. This is okay. The OS scheduler balances your load with
everything else. If you want constant performance then you will need a
realtime OS and a platform other than the web.
If instead I used a value that represents the "amount of simultaneous work
that can be done" (a constantly changing value based on current system
load) to size my threadpool, I would be constantly *resizing* my threadpool
to accommodate for the load. As explained in the previous
navigator.cores/hardwareConcurrency discussions, workers were intentionally
created as very heavyweight interfaces, unlike lightweight native threads
with shared memory. Continuously resizing a worker threadpool only results
in much worse performance due to the worker setup overhead.
My spec is not a measure of simultaneous work that can be done or
performance that can be had. It is a tool for you to use to split up
parallel workloads among multiple processors, independent of system load.
Userspace load balancing is not part of my spec.
You're simultaneously arguing that this value is useful to set up the
size of thread pools but at the same time arguing that the size of the
thread pools isn't important.
Let me put it another way: I believe Webkit is planning on capping the
value of 8. By your argument, if there is too much load for the system,
the "OS scheduler" should "balance your load" and make everything
hunky-dory. In practice, then, why can't applications just set the value
of their thread pool to size 8, and let the OS scheduler sort it out in
the end, if the OS scheduler can handle extra load gracefully?
The number represented by hardwareConcurrency is an inherently dynamic
property, and I don't think the proponents of this API realize that: I
can dynamically change the sets of CPUs to which I will let my program
run (and in fact, I do have use cases for this: high-quality timing
experiments, or binding long-running applications). And it also presumes
that all of the CPUs are going to be more or less available--and despite
your protests to the contrary, even if you put big, bold, flashing red
letters to this effect, developers will end up misinterpreting the API.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
