<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 8, 2014 at 7:01 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</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"><br>
  Mark,<br>
<br>
   Absolutely right and I noted in my first email, the problem is people cannot stop themselves from doing the comparison even when they know that it is wrong. </blockquote><div><br></div><div>Probably but this might be a benign exercise, like debugging code that you see in a presentation, at least for people that understand that sockets have different costs.  </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">An extreme response might be to normalize the curves from each machine so that they all start at the same point and then the only visible information would be the scaling for each machine, not that one curve is consistently above another curve (because of fatter nodes or whatever). Hmm, maybe that is not a bad idea?<br>
</blockquote><div><br></div><div>This would make it easier to distinguish data/trends that log-log smothers.  The "socket" data is useful in that it is "raw" data and difference in performance of a socket is useful, even if not complete without some sort of cost.  The plasma PIC codes that I work with, for instance, generate plots like this (sockets).  I could compare and see how much faster IVB is than BG/Q nodes on these PIC codes and HPGMG. This ratio (Cray/IBM)_PIC /  (Cray/IBM)_HPGMG might be interesting.</div>
</div></div></div>