It's hard to find a proper table (they used to be published), but this may help illustrate the problem:
<http://www.obliquity.com/computer/speedtest.html> If the example program on the page is accurate (and I suspect it is) a floating point add is roughly three times faster than a floating point divide, and more than ten times faster than a floating point cosine. Yet, we count all floating point instructions as one flop. A different processor might be slow to add, or do cosine relatively fast. To do this right, you'd want a benchmark for each operation, and you'd need to know the exact mix of each operation in each science application. ... and that's ignoring the effects of cache size and memory speed, which matters if you have a big data set. It's why when you say "this work unit at s...@h is the benchmark" that you'll guarantee reasonable results for s...@home, and it'll be wrong for most everything else. I don't have an answer, partially because I don't think there is a simple quick-fix. I don't think revaluing credit is an option, so we're stuck with the cobblestone as a unit of measure. Eric Korpela's script seems to do a good job "dialing in" FLOP based credit to match the cobblestone standard. -- Lynn Gabor Gombas wrote: > On Mon, Sep 21, 2009 at 09:28:29AM -0700, Lynn W. Taylor wrote: > >> Unfortunately, at the end of the day, replacing the benchmark with a >> reference work unit is just replacing one arbitrary benchmark with a >> different arbitrary benchmark. >> >> The problem with the existing benchmark is that the benchmark code >> doesn't represent the instruction mix for the project. >> >> When you say "We'll use a specific s...@home work unit as a 'reference' >> work unit" you have the same problem: the instruction mix does not match >> any other project. > > How about having multiple benchmarks: one floating-point intensive, one > data intensive etc., and let applications say "I'm 70% floating point, > 10% integer and 20% memory intensive"? You could even have different > percentages per CPU type. > > Gabor > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
