<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 21, 2015 at 12:23 PM, Justin Chang <span dir="ltr"><<a href="mailto:jychang48@gmail.com" target="_blank">jychang48@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Last question<br><br></div>I would like to report the efficiency of my code. That is, flops/s over the theoretical peak performance (on n-cores). Where the TPP is clock * FLOPS/cycle * n. My current machine is a Intel® Core™ i7-4790 CPU @ 3.60GHz and I am assuming that the FLOPS/cycle is 4. <br><br>One of my serial test runs has achieved a FLOPS/s of 2.01e+09, which translates to an efficiency of almost 14%. I know these are crude measurements but would these manual flop counts be appropriate for this kind of 
measurement? Or would hardware counts from PAPI?<br></div></div></blockquote><div><br></div><div>1) For this, I think the manual counts are good enough for the estimate</div><div><br></div><div>2) You really should not compare to TPP, which ignores memory bandwidth constraints:</div><div><br></div><div>  <a href="http://www.mcs.anl.gov/petsc/documentation/faq.html#computers">http://www.mcs.anl.gov/petsc/documentation/faq.html#computers</a></div><div><br></div><div>You should run the STREAMS benchmark on your machine as the link says, and then</div><div>use a "roofline" model to estimate the peak performance based on bandwidth. Here is</div><div>a talk on that model:</div><div><br></div><div>  <a href="http://crd.lbl.gov/assets/pubs_presos/parlab08-roofline-talk.pdf">http://crd.lbl.gov/assets/pubs_presos/parlab08-roofline-talk.pdf</a></div><div><br></div><div>and here is a paper which does exactly this for sparse MatVec (Krylov methods)</div><div> </div><div>  <a href="http://www.cs.odu.edu/~keyes/papers/pcfd99_gkks.pdf">http://www.cs.odu.edu/~keyes/papers/pcfd99_gkks.pdf</a></div><div><br></div><div>Basically, you have some smaller multiplier to the bandwidth (arithmetic intensity), which</div><div>gives you the real performance upper bound, not TPP.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks,<br></div><div>Justin<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 11:16 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
> Flop is Floating Point Operation. The index calculation is an Integer<br>
> Operation. I agree that we could probably start counting<br>
> those as well since in some sorts of applications its important, but right<br>
> now we don't.<br>
<br>
</span>Index calculations often satisfy recurrences that the compiler folds<br>
into pointer increments and the like.  Also, some architectures, like<br>
PowerPC, have floating point instructions that include mutating index<br>
operations in the true spirit of RISC. ;-)<br>
</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>