From: Rick K. <rk...@il...> - 2009-06-11 21:03:58
|
George, Do you have the raw event counts available to you from each method of measurement you are doing? The metric megaflops is a derived metric, the ratio of floating point operations to cycles, with the clock speed factored in. Either a reduction in floating point operations or an increase in cycles will reduce the value. Unfortunately, there is not enough information here for me to determine the cause of the ~ 6% difference you report. The psrun command will include all event occurrences over the entire run of your program (from the time main() is entered until the program calls exit()). So some time is likely included from within MPI itself, as you guess. You indicate that multiplexing is enabled, so I am guessing you are running psrun with its default configuration file. You may want to try the following: $ psrun -C -c papi3_mflops.xml ./your-program ... as the provided alternate configuration papi3_mflops.xml is one that only counts the two events you are interested in. Multiplexing would likely not be used for such a run. Again: "multiplexing" and "statistical sampling" are two different things, at least in "PerfSuite-speak" Rick George Markomanolis wrote: > Dear Rick, > > First of all thanks for the help, it was a simple problem but because > I am trying a lot of stuff I forgot about it. The problem is solved. > About my second question. Basically I want to measure only two > hardware counters PAPI_FP_OPS and PAPI_TOT_CYC in order to take > Mflops. I ask about how accurate it is because I compared results from > profiling matrix multipication (C, MPI, ScalaPack with psrun) with > another profiling tool and with perfsuite I had 960 mflops per cpu but > with the other one almost 1020 mflops. Multiplexing was enabled, so is > it possible to loose so many flops? Also PerfSuite measure also MPI > command's flops (all_reduce etc?). I was trying to figure out why > there was such a difference. If PerfSuite use statistical sampling > then it is possible to loose some data? > > Best regards, > George Markomanolis > |