On Tue, 25 Nov 2008, Paul Biggar wrote: > I suppose the best thing for me is to take the caches and branch > mispredictions into account alongside instruction references. Using > calibrator I can probably come up with a single number with which to > compare revisions. I'll have to use wall clock time for publication > though.
You might find this paper interesting: http://www.cs.mu.oz.au/~njn/pubs/cache-large-lazy2002.ps In it, I was able to find a simple model that just included instructions, cache misses and branch mispredictions, and which did a pretty good job of predicting the run-time of various Haskell programs. But this doesn't work in general, and indicated that the Haskell programs were quite unusual. And the machine was from about 2001, so the hardware for newer machines will be substantially different. Furthermore, I got the numbers from hardware counters. Cachegrind's numbers are less accurate -- see section 3.3.7 of http://www.cs.mu.oz.au/~njn/pubs/phd2004.pdf for all the reasons why. For publications you should use wall clock time as the definitive number, you'll get mauled by reviewers if you try anything else. Once you've got the wall clock times, you could possibly use Cachegrind numbers to explain differences, so long as you explain that Cachegrind has inaccuracies and its numbers are a useful guide rather than definitive. Nick ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
