On Mon, May 05, 2014 at 07:31:15PM -0400, Eli Grey wrote: > I have a list of example use cases at > http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases > > Each of these use cases involves a parallelizable algorithm that needs > to run as fast as possible on the user's system in order for the user > to have a responsive experience. You can never run any of these > algorithms "too" fast/with "too many" resources. It's all part of the > race to sleep/idle.
The algorithms don't have to run as fast as possible, they only have to run fast enough that the system is responsive to the user. If there is a motion graphic, you need to run the algorithm fast enough that the motion isn't choppy. If the user interacts with the app, then if the app responds in <100ms to commands/gestures, that's often as good as instantaneous as far as human perception goes. If you're running the algorithm any faster than the lowest responsive rate (e.g., 3,000 frames per second is probably too fast), you're taking an unnecessary share of the CPU resource. You're probably running the computer hot and loud, too. Let me suggest an approach to scaling the number of threads for performance that does not require the core count or maximum concurrency or any one-dimensional measure like that. Set a latency goal for your motion/input response. Create one worker thread for your algorithm. Track the rate of work completion. Fast enough to meet your goal? If not, create another worker thread. Fast enough? If not, create another worker. Keep tracking. At some point you will reach a point of diminishing returns---in fact, you may actually move *away* from your goal by adding threads. Add no more threads at that point. Track your performance against the goal always. If you start exceeding your goal by a large margin, cancel a worker. Various refinements to the approach are possible. For example, you could start with more than one worker thread. Also, you could increase/decrease the number of threads in a different way: double/halve, or increase in proportion to the performance boost you hope for. Is there some reason that the web platform does not support this approach? Is there some reason that this approach doesn't fit the use cases you mention? Dave -- David Young dyo...@pobox.com Urbana, IL (217) 721-9981