Re: [whatwg] Proposal: navigator.cores

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
dyoung@pobox.com    Urbana, IL    (217) 721-9981

Received on Friday, 9 May 2014 14:57:23 UTC