Hi Josef, Thanks for getting back to me so quickly.
On Mon, Nov 24, 2008 at 6:55 PM, Josef Weidendorfer <[EMAIL PROTECTED]> wrote: > Hmm. Perhaps speedup in terms of executed instructions. However, > the term "speedup" is usually used for runtime improvement... Well, yeah. I was kinda deliberately fudging my terms, but I hadnt made that clear. Sorry. >> I find >> these results to be consistent on this machine, if I ignore that last >> 4 digits or so. > > What do you mean by 'consistent' here? Real measurement of instructions > executed via a performance counter? I meant that if I ran the same program twice, I got almost the same results (vs using clock time, where it varies quite wildly between runs of the same program). > But if you talk about the relation of your instruction speedup to actual > time speedup on your machine, then this is only true by chance, for your > specific code. Yes, I wasnt looking to correlate these. That would have been some fluke. > In another code, one instruction doing a memory access could need as > much time as 100 instructions doing integer operations... > >> I'd like to know how reliable I can consider this number to be: >> - Could it be considered an accurate reflection of how long my >> program will take to run? > > No. Right, that should have been obvious. >> - Can I consider the number to be consistent between different >> versions of cachegrind? > > As far as I know, the semantic behind Ir did not change in the past. > </snip> >> - Will it be forward-compatible with future versions? > > Probably, yes. OK, that's good to know. >> - Can I expect the results to be the same on different >> OS/architecture combinations? > > No. Depending on the compiler & architecture, for the same problem > there of course can be code generated with different numbers of > instructions. Right, this should have been obvious too. Apologies for the silly questions. >> Finally, would you consider it to be 'safe' to include these numbers >> in a submission to a peer-reviewed publication? The idea would be that >> instead of using performance results that are fickle - depending on >> the load on my machine, my configuration, CPU etc - I could quote a >> number which would be reproducible on another machine. > > As said above, cachegrinds Ir numbers say nothing about performance on > a real machine. They never will be a replacement for real time measurements. Yes, thats clear to me now. > However, if you assume a simple machine model (doing 1 instruction per time > step), the "Ir" numbers would be a good estimation of performance in this > model. As you say, this isnt a very good model. > PS: A better (but still rough) time estimation is to take the cache misses > into > account, which cachegrind can provide. 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. Thanks very much for you answers. They were very helpful. Paul -- Paul Biggar [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
