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