On Fri, May 09, 2014 at 11:05:03AM -0500, Glenn Maynard wrote:
> On Fri, May 9, 2014 at 9:56 AM, David Young <dyo...@pobox.com> wrote:
> > 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.
> That's not correct.  For image processing and compression, you want to use
> as many cores as you can so the operation completes more quickly.

Sounds like a latency goal to me.  I think that it's probably a set of
latency goals.  For example, finish the work before

        the user notices ("instantly"---100ms or less)

        the user's attention is lost or patience runs out---5 to
            10 seconds, depending on the user

        the user has finished checking their email

        the user is late for their lunch appointment

        the user has finished lunch

        the user wakes up the next morning

If I'm going to take a coffee break or go check my email, anyway, then
the difference between "as quickly as possible" and 150% longer than
that may not even matter.  Five minutes?  Or seven and a half?  Meh. :-)

Also, a web app should use only as many threads as it takes to improve
the performance.  If you use too many, you may decrease performance, and
I don't think a solitary number tells you how many is too many, because
not all logical CPUs are created equal, and not only because their clock
speeds may differ.

> For the
> rest, using more cores means that the algorithm can do a better job, giving
> a more accurate physics simulation, detecting motion more quickly and
> accurately, and so on.

Again, I see an implicit latency goal, and if all of the results are
late, it doesn't really matter how accurate they are.


David Young
dyo...@pobox.com    Urbana, IL    (217) 721-9981

Reply via email to