<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Since ‘nodes’  seems to be the standard unit of allocation on compute platforms I still prefer nodes as a scaling.  When I start getting charged by the Joule I will desire an unambiguous way of measuring Joules to make sure the users are treated fairly.  <div><br></div><div>I know that my own host site NERSC uses hours*nodes*cores/node  which would seem to indicate people are core-counting, but perhaps Edison is the last of the truly Fat core platforms we will see and we will go back to allocation awards being in units of nodes.<br><div><br></div><div>to get around core/node/socket/accelerator/etc  you would probably have to drop all the way down to transistors, or better, die area.  Even that can be complicated for how you sum up SoC real estate.</div><div><br></div><div>If the various computing centers can figure out how to normalize their users across platforms then we should use the same normalization.</div><div><br></div><div>Brian</div><div><br><div><div>On Jun 8, 2014, at 7:54 AM, Constantinos Evangelinos <<a href="mailto:cevange@us.ibm.com">cevange@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><p><font size="2" face="sans-serif">In my mind at least users ask a queuing system in most cases for nodes as node sharing is discouraged for obvious reasons. So nodes seems to me to be the most useful x-axis choice. Cores is problematic as (a) they get added in large block increments and (b) it stretches the axes a lot even without thinking of GPUs with the relatively wimpy cores in BG/Q and Xeon Phi.<br>
</font><font size="2" face="sans-serif"><br>
</font><font size="2" face="sans-serif">Constantinos <br>
</font><font size="2" face="sans-serif"><br>
</font><font size="2" face="sans-serif">Sent from my iPhone so please excuse any typing errors<br>
</font><font size="2" face="sans-serif"><br>
</font><font size="2" face="sans-serif">> On Jun 7, 2014, at 7:01 PM, "Sam Williams" <<a href="mailto:swwilliams@lbl.gov">swwilliams@lbl.gov</a>> wrote:<br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> Nominally, there would be a paragraph describing the setup for a figure.  For this data, the x-axis is what is colloquially defined today as a numa node on the Cray machines.  There is one process per numa node.  Thus, for all of these machines, there is one process per chip.<br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> K = 1 processes per compute node, 8 threads per process<br>
</font><font size="2" face="sans-serif">> BGQ = 1 process per compute node, 64 threads per process<br>
</font><font size="2" face="sans-serif">> Edison = 2 processes per compute node, 12 threads per process<br>
</font><font size="2" face="sans-serif">> Peregrine = 2 processes per compute node, 12 threads per process<br>
</font><font size="2" face="sans-serif">> Hopper = 4 processes per compute node, 6 threads per process<br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> On Jun 7, 2014, at 3:51 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> ><br>
</font><font size="2" face="sans-serif">> >  I submit that even nodes or “sockets” is actually not completely unambiguous<br>
</font><font size="2" face="sans-serif">> ><br>
</font><font size="2" face="sans-serif">> > On Jun 7, 2014, at 5:39 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
</font><font size="2" face="sans-serif">> ><br>
</font><font size="2" face="sans-serif">> >> On Sat, Jun 7, 2014 at 3:35 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
</font><font size="2" face="sans-serif">> >>><br>
</font><font size="2" face="sans-serif">> >>> On Jun 7, 2014, at 5:31 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
</font><font size="2" face="sans-serif">> >>><br>
</font><font size="2" face="sans-serif">> >>>> On Sat, Jun 7, 2014 at 3:26 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
</font><font size="2" face="sans-serif">> >>>>><br>
</font><font size="2" face="sans-serif">> >>>>> The use of multicore processor == sockets as the independent variable in the plot of aggregate performance seems arbitrary. Though people should not use this kind of plot to compare machines they will. Now just change sockets to nodes and boom suddenly the machines compare very differently (since some systems have two sockets per node and some one). Should cores be used instead? Or hardware threads? Or cores scaled by their clock speed? Or hardware floating point units (scaled by clock speed?) ? Or number of instruction decorders? Power usage? Cost? etc etc. Maybe have a dynamic plot where one can switch the independent variable by selecting from a menu or moving the mouse over choices ….?<br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>  Yes, but how do we measure power? The actual amount being pulled from the “wall socket”? Is that possible? Like the various hardware features you mention I wouldn’t trust anything the vendor says about power.<br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >> Assuming you run on more than one node, just use the total machine<br>
</font><font size="2" face="sans-serif">> >> power that is used by Green500.  Granted, that is not ideal since it<br>
</font><font size="2" face="sans-serif">> >> won't be measured for the same code, but at least there is a<br>
</font><font size="2" face="sans-serif">> >> well-defined procedure for measuring it and hopefully it is at least<br>
</font><font size="2" face="sans-serif">> >> roughly comparable between systems.<br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >> But I agree that power is nearly as hard to get exactly right as<br>
</font><font size="2" face="sans-serif">> >> anything else besides counting nodes.  That is about the only<br>
</font><font size="2" face="sans-serif">> >> independent variable that seems unambiguous.<br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >> Jeff<br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >>>> The last suggestion is obviously the best one since it is the most<br>
</font><font size="2" face="sans-serif">> >>>> general, but I think power is the best choice of independent variable.<br>
</font><font size="2" face="sans-serif">> >>>> Most of the other hardware features are bad choices because it is very<br>
</font><font size="2" face="sans-serif">> >>>> hard to determine some of these.  What is the clock speed of an Intel<br>
</font><font size="2" face="sans-serif">> >>>> socket that does dynamic frequency scaling?  How do you count cores on<br>
</font><font size="2" face="sans-serif">> >>>> a GPU?  NVIDIA's core-counting methodology is complete nonsense...<br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>> Best,<br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>> Jeff<br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>>> On Jun 7, 2014, at 4:27 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
</font><font size="2" face="sans-serif">> >>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
</font><font size="2" face="sans-serif">> >>>>>>> We are please to announce that <a href="http://hpgmg.org">hpgmg.org</a> and the associated mailing<br>
</font><font size="2" face="sans-serif">> >>>>>>> list <a href="mailto:hpgmg-forum@hpgmg.org">hpgmg-forum@hpgmg.org</a> is officially available.<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> Thanks, Mark.  To help kick off the discussion, I would like to call<br>
</font><font size="2" face="sans-serif">> >>>>>> attention to our recent blog posts describing "results".<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> The most recent announces the v0.1 release and includes a Kiviat diagram<br>
</font><font size="2" face="sans-serif">> >>>>>> comparing the on-node performance characteristics of CORAL apps and<br>
</font><font size="2" face="sans-serif">> >>>>>> several benchmarks running on Blue Gene/Q.<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="https://hpgmg.org/2014/06/06/hpgmg-01/">https://hpgmg.org/2014/06/06/hpgmg-01/</a><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> This earlier post shows performance on a variety of top machines:<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="https://hpgmg.org/2014/05/15/fv-results/">https://hpgmg.org/2014/05/15/fv-results/</a><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> We are interested in better ways to collect and present the comparison<br>
</font><font size="2" face="sans-serif">> >>>>>> data as well as any characteristics that you think are important.<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> In addition to the general principles on the front page, some further<br>
</font><font size="2" face="sans-serif">> >>>>>> rationale is given at:<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="https://hpgmg.org/why/">https://hpgmg.org/why/</a><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> None of this is set in stone and we would be happy to discuss any<br>
</font><font size="2" face="sans-serif">> >>>>>> questions or comments on this list.<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> Please encourage any interested colleagues to subscribe to this list:<br>
</font><font size="2" face="sans-serif">> >>>>>><br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</font><font size="2" face="sans-serif">> >>>>>> _______________________________________________<br>
</font><font size="2" face="sans-serif">> >>>>>> HPGMG-Forum mailing list<br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
</font><font size="2" face="sans-serif">> >>>>>> <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</font><font size="2" face="sans-serif">> >>>>><br>
</font><font size="2" face="sans-serif">> >>>>> _______________________________________________<br>
</font><font size="2" face="sans-serif">> >>>>> HPGMG-Forum mailing list<br>
</font><font size="2" face="sans-serif">> >>>>> <a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
</font><font size="2" face="sans-serif">> >>>>> <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>><br>
</font><font size="2" face="sans-serif">> >>>> --<br>
</font><font size="2" face="sans-serif">> >>>> Jeff Hammond<br>
</font><font size="2" face="sans-serif">> >>>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
</font><font size="2" face="sans-serif">> >>>> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>
</font><font size="2" face="sans-serif">> >>><br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >><br>
</font><font size="2" face="sans-serif">> >> --<br>
</font><font size="2" face="sans-serif">> >> Jeff Hammond<br>
</font><font size="2" face="sans-serif">> >> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
</font><font size="2" face="sans-serif">> >> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>
</font><font size="2" face="sans-serif">> ><br>
</font><font size="2" face="sans-serif">> > _______________________________________________<br>
</font><font size="2" face="sans-serif">> > HPGMG-Forum mailing list<br>
</font><font size="2" face="sans-serif">> > <a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
</font><font size="2" face="sans-serif">> > <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</font><font size="2" face="sans-serif">> <br>
</font><font size="2" face="sans-serif">> _______________________________________________<br>
</font><font size="2" face="sans-serif">> HPGMG-Forum mailing list<br>
</font><font size="2" face="sans-serif">> <a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
</font><font size="2" face="sans-serif">> <a href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
</font><font size="2" face="sans-serif">> <br>
</font></p></div>_______________________________________________<br>HPGMG-Forum mailing list<br><a href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>https://hpgmg.org/lists/listinfo/hpgmg-forum<br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div><div><font class="Apple-style-span" face="'Courier New'">Brian Van Straalen         Lawrence Berkeley Lab</font></div><div><font class="Apple-style-span" face="'Courier New'"><a href="mailto:BVStraalen@lbl.gov">BVStraalen@lbl.gov</a>         Computational Research</font></div><div><font class="Apple-style-span" face="'Courier New'">(510) 486-4976             Division (<a href="http://crd.lbl.gov">crd.lbl.gov</a>)</font></div></div><div><br></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>