<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Mark et. al.<br>
    <br>
     I would love to contribute. <br>
    <br>
    Theo<br>
    <br>
    <div class="moz-cite-prefix">On 6/9/2014 9:47 AM, Mark Adams wrote:<br>
    </div>
    <blockquote
cite="mid:CADOhEh4wp0Z_VXBZ8TJ-T=C2VWwuf52PFhy9PHv2ESbVWHxzQA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Theo,
        <div><br>
        </div>
        <div>This looks like a good suggestion for taking our modeling
          effort to the next level.  </div>
        <div><br>
        </div>
        <div>We are all volunteering at this point.  We hope to get
          funding from DOE-ASCR in say the next year and some of us have
          an LDRD pending.  Our modeling effort has fallen through the
          cracks because no one has done it.  I have stepped up and
          collected some data, and the LLNL folks have been generous in
          sharing their app, HPL, and HPCG data, so that we have
          something (I am speaking at ISC at the end of this month) but
          it needs work.</div>
        <div><br>
        </div>
        <div>If you would like to contribute to this then you are
          welcome.  We want to have a set of metrics like what you have
          listed and a mechanism to collect the data from multiple
          architectures, or at least get the data.  I'm worried that it
          might be hard to get all of these metrics form multiple
          platforms and have them be comparable but this is not by
          business.  There are CORAL Benchmark codes, HPGMG-FV,
          HPGMG-FE, and data from HPL might be interesting (or maybe
          not).  HPCG is a moving target but a least a snapshot from
          them might be nice.  We would like to get data on apps and
          HPGMG and work on fitting what free parameters we have in the
          HPGMG specification to applications.  I would think we would
          want some infrastructure in the repo to facilitate the ongoing
          collection of this data but I really don't know what form this
          should take.  Let us know if you have any thoughts and, again,
          we welcome any contribution that you might want to make.</div>
        <div><br>
        </div>
        <div>Mark</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Mon, Jun 9, 2014 at 5:10 AM,
          Theodore Omtzigt <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:theo@stillwater-sc.com" target="_blank">theo@stillwater-sc.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> Barry:<br>
              <br>
                The pro for normalization would be that it is empirical
              and thus a complex mixture of software and hardware
              interactions. The resulting curves would indeed be perfect
              for comparisons of scaling. But that empirical
              normalization could also be argued is a con as it does not
              provide any insight what resource in the machine is
              causing more or less scaling capability.<br>
              <br>
              As always, depending on the question you need to answer,
              you want to see different Kaviat graphs. As a hardware
              designer, I would like to see how well a particular
              resource allocation is helping the performance of an
              application. As all machines have a common collection of
              resources, the Kaviat's that I am interested would capture
              those, in particular this list:<br>
              <br>
              FPU sp peak throughput<br>
              FPU dp peak  (big difference in silicon allocation)<br>
              IU peak throughput<br>
              L1 bw peak (latency is governed by core clock, but bw is
              parallelism on the cache ports)<br>
              L2 bw peak (latency becomes an issue further away, but
              most L2s are supporting fast L1 refresh)<br>
              L3 bw peak<br>
              L3 size<br>
              FSB bw peak<br>
              Memory latency (for low-concurrency kernels this is the
              bottleneck)<br>
              Memory bw peak<br>
              Network latency<br>
              Network bw peak<br>
              Reduction peak throughput<br>
              Broadcast peak throughput<br>
              <br>
              The beauty of this list is that it is uniform across all
              machines, including non-von Neumann. It focuses on the
              actual hardware that delivers computation. Most hardware
              is designed from this core on out, that is, you set a
              particular FPU throughput rate, and from that point on you
              are trying to remove resource bottlenecks till you can
              reach that throughput rate on the key kernels you
              selected. <br>
              <br>
              These Kaviats would also be helpful for the application
              community as it shows you the resource efficiency of your
              algorithm for a particular machine.<br>
              <br>
              Theo<br>
               <br>
              <div>On 6/9/2014 7:30 AM, <a moz-do-not-send="true"
                  href="mailto:hpgmg-forum-request@hpgmg.org"
                  target="_blank">hpgmg-forum-request@hpgmg.org</a>
                wrote:<br>
              </div>
              <blockquote type="cite">
                <pre>Send HPGMG-Forum mailing list submissions to
        <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank">hpgmg-forum@hpgmg.org</a>

To subscribe or unsubscribe via the World Wide Web, visit
        <a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
or, via email, send a message with subject or body 'help' to
        <a moz-do-not-send="true" href="mailto:hpgmg-forum-request@hpgmg.org" target="_blank">hpgmg-forum-request@hpgmg.org</a>

You can reach the person managing the list at
        <a moz-do-not-send="true" href="mailto:hpgmg-forum-owner@hpgmg.org" target="_blank">hpgmg-forum-owner@hpgmg.org</a>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of HPGMG-Forum digest..."


Today's Topics:

   1. Re:  HPGMG release v0.1 (Barry Smith)
   2. Re:  HPGMG release v0.1 (Jed Brown)
   3. Re:  HPGMG release v0.1 (Jed Brown)
   4. Re:  HPGMG release v0.1 (Jed Brown)
   5.  Reuse of Kiviat diagram? (Karl Rupp)
   6. Re:  Reuse of Kiviat diagram? (Jed Brown)
   7. Re:  HPGMG release v0.1 (Mark Adams)


----------------------------------------------------------------------

Message: 1
Date: Sun, 8 Jun 2014 21:01:51 -0500
From: Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a>
To: Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a>
Cc: HPGMG Forum <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: Re: [HPGMG Forum] HPGMG release v0.1
Message-ID: <a moz-do-not-send="true" href="mailto:A89223F3-D0E8-41A7-9FA8-2E33E82D5A50@mcs.anl.gov" target="_blank"><A89223F3-D0E8-41A7-9FA8-2E33E82D5A50@mcs.anl.gov></a>
Content-Type: text/plain; charset="windows-1252"


  Mark,

   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. 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?

   Barry

On Jun 8, 2014, at 8:46 PM, Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a> wrote:

</pre>
                <blockquote type="cite">
                  <pre>This is a great discussion.  

As a more immediate matter, we should make clear that these are superimposed plots and a "socket" is not comparable in general (Edison and Peregrine in fact are).  These plots do not imply that a Cray XC30/Aries is a better HPGMG machine than BG/Q or K, for instance, but you can see that Aries is scaling noticeably better than Gemini and Infiniband on HPGMG (and HPL would probably not distinguish these interconnects).  We should try to make that clear in presentations and perhaps we (ie, Jed) could add a little disclaimer to this effect on this web page, seeing as it has gotten so much attention here.

Mark


On Sun, Jun 8, 2014 at 3:12 PM, Brian Van Straalen <a moz-do-not-send="true" href="mailto:bvstraalen@lbl.gov" target="_blank"><bvstraalen@lbl.gov></a> wrote:
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.  

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.

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.

If the various computing centers can figure out how to normalize their users across platforms then we should use the same normalization.

Brian

On Jun 8, 2014, at 7:54 AM, Constantinos Evangelinos <a moz-do-not-send="true" href="mailto:cevange@us.ibm.com" target="_blank"><cevange@us.ibm.com></a> wrote:

</pre>
                  <blockquote type="cite">
                    <pre>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.

Constantinos 

Sent from my iPhone so please excuse any typing errors

</pre>
                    <blockquote type="cite">
                      <pre>On Jun 7, 2014, at 7:01 PM, "Sam Williams" <a moz-do-not-send="true" href="mailto:swwilliams@lbl.gov" target="_blank"><swwilliams@lbl.gov></a> wrote:

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.

K = 1 processes per compute node, 8 threads per process
BGQ = 1 process per compute node, 64 threads per process
Edison = 2 processes per compute node, 12 threads per process
Peregrine = 2 processes per compute node, 12 threads per process
Hopper = 4 processes per compute node, 6 threads per process




On Jun 7, 2014, at 3:51 PM, Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> wrote:

</pre>
                      <blockquote type="cite">
                        <pre> I submit that even nodes or ?sockets? is actually not completely unambiguous

On Jun 7, 2014, at 5:39 PM, Jeff Hammond <a moz-do-not-send="true" href="mailto:jeff.science@gmail.com" target="_blank"><jeff.science@gmail.com></a> wrote:

</pre>
                        <blockquote type="cite">
                          <pre>On Sat, Jun 7, 2014 at 3:35 PM, Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> wrote:
</pre>
                          <blockquote type="cite">
                            <pre>On Jun 7, 2014, at 5:31 PM, Jeff Hammond <a moz-do-not-send="true" href="mailto:jeff.science@gmail.com" target="_blank"><jeff.science@gmail.com></a> wrote:

</pre>
                            <blockquote type="cite">
                              <pre>On Sat, Jun 7, 2014 at 3:26 PM, Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> wrote:
</pre>
                              <blockquote type="cite">
                                <pre>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 ?.?
</pre>
                              </blockquote>
                            </blockquote>
                            <pre> 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.
</pre>
                          </blockquote>
                          <pre>Assuming you run on more than one node, just use the total machine
power that is used by Green500.  Granted, that is not ideal since it
won't be measured for the same code, but at least there is a
well-defined procedure for measuring it and hopefully it is at least
roughly comparable between systems.

But I agree that power is nearly as hard to get exactly right as
anything else besides counting nodes.  That is about the only
independent variable that seems unambiguous.

Jeff

</pre>
                          <blockquote type="cite">
                            <blockquote type="cite">
                              <pre>The last suggestion is obviously the best one since it is the most
general, but I think power is the best choice of independent variable.
Most of the other hardware features are bad choices because it is very
hard to determine some of these.  What is the clock speed of an Intel
socket that does dynamic frequency scaling?  How do you count cores on
a GPU?  NVIDIA's core-counting methodology is complete nonsense...

Best,

Jeff


</pre>
                              <blockquote type="cite">
                                <pre>On Jun 7, 2014, at 4:27 PM, Jed Brown <a moz-do-not-send="true" href="mailto:jed@jedbrown.org" target="_blank"><jed@jedbrown.org></a> wrote:

</pre>
                                <blockquote type="cite">
                                  <pre>Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a> writes:
</pre>
                                  <blockquote type="cite">
                                    <pre>We are please to announce that <a moz-do-not-send="true" href="http://hpgmg.org" target="_blank">hpgmg.org</a> and the associated mailing
list <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank">hpgmg-forum@hpgmg.org</a> is officially available.
</pre>
                                  </blockquote>
                                  <pre>Thanks, Mark.  To help kick off the discussion, I would like to call
attention to our recent blog posts describing "results".

The most recent announces the v0.1 release and includes a Kiviat diagram
comparing the on-node performance characteristics of CORAL apps and
several benchmarks running on Blue Gene/Q.

<a moz-do-not-send="true" href="https://hpgmg.org/2014/06/06/hpgmg-01/" target="_blank">https://hpgmg.org/2014/06/06/hpgmg-01/</a>


This earlier post shows performance on a variety of top machines:

<a moz-do-not-send="true" href="https://hpgmg.org/2014/05/15/fv-results/" target="_blank">https://hpgmg.org/2014/05/15/fv-results/</a>


We are interested in better ways to collect and present the comparison
data as well as any characteristics that you think are important.


In addition to the general principles on the front page, some further
rationale is given at:

<a moz-do-not-send="true" href="https://hpgmg.org/why/" target="_blank">https://hpgmg.org/why/</a>

None of this is set in stone and we would be happy to discuss any
questions or comments on this list.


Please encourage any interested colleagues to subscribe to this list:

<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                                </blockquote>
                                <pre>_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                              </blockquote>
                              <pre>
--
Jeff Hammond
<a moz-do-not-send="true" href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>
<a moz-do-not-send="true" href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a>
</pre>
                            </blockquote>
                          </blockquote>
                          <pre>
--
Jeff Hammond
<a moz-do-not-send="true" href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>
<a moz-do-not-send="true" href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a>
</pre>
                        </blockquote>
                        <pre>_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                      </blockquote>
                      <pre>_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>

</pre>
                    </blockquote>
                    <pre>_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                  </blockquote>
                  <pre>Brian Van Straalen         Lawrence Berkeley Lab
<a moz-do-not-send="true" href="mailto:BVStraalen@lbl.gov" target="_blank">BVStraalen@lbl.gov</a>         Computational Research
<a moz-do-not-send="true" href="tel:%28510%29%20486-4976" value="+15104864976" target="_blank">(510) 486-4976</a>             Division (<a moz-do-not-send="true" href="http://crd.lbl.gov" target="_blank">crd.lbl.gov</a>)





_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>


_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                </blockquote>
                <pre>
------------------------------

Message: 2
Date: Mon, 09 Jun 2014 08:46:42 +0200
From: Jed Brown <a moz-do-not-send="true" href="mailto:jed@jedbrown.org" target="_blank"><jed@jedbrown.org></a>
To: Brian Van Straalen <a moz-do-not-send="true" href="mailto:bvstraalen@lbl.gov" target="_blank"><bvstraalen@lbl.gov></a>, Constantinos Evangelinos
        <a moz-do-not-send="true" href="mailto:cevange@us.ibm.com" target="_blank"><cevange@us.ibm.com></a>
Cc: HPGMG Forum <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: Re: [HPGMG Forum] HPGMG release v0.1
Message-ID: <a moz-do-not-send="true" href="mailto:87r42ya8bx.fsf@jedbrown.org" target="_blank"><87r42ya8bx.fsf@jedbrown.org></a>
Content-Type: text/plain; charset="us-ascii"

Brian Van Straalen <a moz-do-not-send="true" href="mailto:bvstraalen@lbl.gov" target="_blank"><bvstraalen@lbl.gov></a> writes:
</pre>
                <blockquote type="cite">
                  <pre>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.
</pre>
                </blockquote>
                <pre>NERSC has a different charge factor for Edison versus Hopper (and
different factors for different queues).  The x axis is arbitrary,
serving only to quantify run size in units that can be interpreted
separately for each machine.  Slope and maximum value are the quantities
that are meaningful to compare.

Sam, I think that counting NUMA nodes, while principled and relevant to
the implementation, is ultimately confusing and prone to
misinterpretation.  Would you mind regenerating this figure with x axis
representing compute nodes (the unit in which users of the machine
count)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <a moz-do-not-send="true" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/d818bb44/attachment-0001.bin" target="_blank"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/d818bb44/attachment-0001.bin></a>

------------------------------

Message: 3
Date: Mon, 09 Jun 2014 09:00:59 +0200
From: Jed Brown <a moz-do-not-send="true" href="mailto:jed@jedbrown.org" target="_blank"><jed@jedbrown.org></a>
To: Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a>, Brian Van Straalen
        <a moz-do-not-send="true" href="mailto:bvstraalen@lbl.gov" target="_blank"><bvstraalen@lbl.gov></a>
Cc: HPGMG Forum <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: Re: [HPGMG Forum] HPGMG release v0.1
Message-ID: <a moz-do-not-send="true" href="mailto:87oay2a7o4.fsf@jedbrown.org" target="_blank"><87oay2a7o4.fsf@jedbrown.org></a>
Content-Type: text/plain; charset="us-ascii"

Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a> writes:

</pre>
                <blockquote type="cite">
                  <pre>This is a great discussion.

As a more immediate matter, we should make clear that these are
superimposed plots and a "socket" is not comparable in general (Edison and
Peregrine in fact are).  These plots do not imply that a Cray XC30/Aries is
a better HPGMG machine than BG/Q or K, for instance, but you can see that
Aries is scaling noticeably better than Gemini and Infiniband on HPGMG (and
HPL would probably not distinguish these interconnects).  We should try to
make that clear in presentations and perhaps we (ie, Jed) could add a
little disclaimer to this effect on this web page, seeing as it has gotten
so much attention here.
</pre>
                </blockquote>
                <pre>I added an update which I hope clarifies matters.

<a moz-do-not-send="true" href="https://bitbucket.org/hpgmg/hpgmg.org/commits/b820cd0771699f46cdf65912a47f58330ba9d0bb" target="_blank">https://bitbucket.org/hpgmg/hpgmg.org/commits/b820cd0771699f46cdf65912a47f58330ba9d0bb</a>

All, feel free to change further.  (Submit a pull request or send a
patch to the mailing list if you don't have write access to this
repository.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <a moz-do-not-send="true" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/77bf77ce/attachment-0001.bin" target="_blank"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/77bf77ce/attachment-0001.bin></a>

------------------------------

Message: 4
Date: Mon, 09 Jun 2014 09:02:07 +0200
From: Jed Brown <a moz-do-not-send="true" href="mailto:jed@jedbrown.org" target="_blank"><jed@jedbrown.org></a>
To: Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a>, Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a>
Cc: HPGMG Forum <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: Re: [HPGMG Forum] HPGMG release v0.1
Message-ID: <a moz-do-not-send="true" href="mailto:87lht6a7m8.fsf@jedbrown.org" target="_blank"><87lht6a7m8.fsf@jedbrown.org></a>
Content-Type: text/plain; charset="us-ascii"

Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> writes:
</pre>
                <blockquote type="cite">
                  <pre>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).
</pre>
                </blockquote>
                <pre>This would prevent comparison of the maximum values.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <a moz-do-not-send="true" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/e7e40c25/attachment-0001.bin" target="_blank"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/e7e40c25/attachment-0001.bin></a>

------------------------------

Message: 5
Date: Mon, 9 Jun 2014 11:36:10 +0200
From: Karl Rupp <a moz-do-not-send="true" href="mailto:rupp@iue.tuwien.ac.at" target="_blank"><rupp@iue.tuwien.ac.at></a>
To: <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: [HPGMG Forum] Reuse of Kiviat diagram?
Message-ID: <a moz-do-not-send="true" href="mailto:5395800A.1020307@iue.tuwien.ac.at" target="_blank"><5395800A.1020307@iue.tuwien.ac.at></a>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

Hi guys,

congratulations on HPGMG, this is a great piece of work, as it addresses 
the shortcomings of the 'big benchmarks' in use. I'd like to write a 
blog post, summarizing the better balance of HPGMG, for which I plan to 
adapt your Kiviat diagram [1] a little (adding a few arrows and labels). 
Do I get your permission for altering the graph and for using it in my 
blog? References and links will of course be set appropriately.

Thanks and best regards,
Karli

[1] <a moz-do-not-send="true" href="https://hpgmg.org/images/hpgmg-kiviat-20140606.png" target="_blank">https://hpgmg.org/images/hpgmg-kiviat-20140606.png</a>


------------------------------

Message: 6
Date: Mon, 09 Jun 2014 11:58:55 +0200
From: Jed Brown <a moz-do-not-send="true" href="mailto:jed@jedbrown.org" target="_blank"><jed@jedbrown.org></a>
To: Karl Rupp <a moz-do-not-send="true" href="mailto:rupp@iue.tuwien.ac.at" target="_blank"><rupp@iue.tuwien.ac.at></a>, <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank">hpgmg-forum@hpgmg.org</a>
Subject: Re: [HPGMG Forum] Reuse of Kiviat diagram?
Message-ID: <a moz-do-not-send="true" href="mailto:87y4x68kv4.fsf@jedbrown.org" target="_blank"><87y4x68kv4.fsf@jedbrown.org></a>
Content-Type: text/plain; charset="us-ascii"

Ian and Bert, do I understand correctly that you got approval for public
release of the spreadsheet (not just to those of us at LBNL and ANL)?

Mark, I think you added the most recent data.  Can you add it to the
website repository (place in content/static/ and link from the blog
post) or send to me and I'll do it.

Karl Rupp <a moz-do-not-send="true" href="mailto:rupp@iue.tuwien.ac.at" target="_blank"><rupp@iue.tuwien.ac.at></a> writes:

</pre>
                <blockquote type="cite">
                  <pre>Hi guys,

congratulations on HPGMG, this is a great piece of work, as it addresses 
the shortcomings of the 'big benchmarks' in use. I'd like to write a 
blog post, summarizing the better balance of HPGMG, for which I plan to 
adapt your Kiviat diagram [1] a little (adding a few arrows and labels). 
Do I get your permission for altering the graph and for using it in my 
blog? References and links will of course be set appropriately.

Thanks and best regards,
Karli

[1] <a moz-do-not-send="true" href="https://hpgmg.org/images/hpgmg-kiviat-20140606.png" target="_blank">https://hpgmg.org/images/hpgmg-kiviat-20140606.png</a>
_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                </blockquote>
                <pre>-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <a moz-do-not-send="true" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/4cbfe2b8/attachment-0001.bin" target="_blank"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/4cbfe2b8/attachment-0001.bin></a>

------------------------------

Message: 7
Date: Mon, 9 Jun 2014 04:30:09 -0700
From: Mark Adams <a moz-do-not-send="true" href="mailto:mfadams@lbl.gov" target="_blank"><mfadams@lbl.gov></a>
To: Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a>
Cc: HPGMG Forum <a moz-do-not-send="true" href="mailto:hpgmg-forum@hpgmg.org" target="_blank"><hpgmg-forum@hpgmg.org></a>
Subject: Re: [HPGMG Forum] HPGMG release v0.1
Message-ID:
        <a moz-do-not-send="true" href="mailto:CADOhEh6uLq+y69CPh_Lz1QbpQA3RUm4b0m_yys05PqMv3qY1Ew@mail.gmail.com" target="_blank"><CADOhEh6uLq+y69CPh_Lz1QbpQA3RUm4b0m_yys05PqMv3qY1Ew@mail.gmail.com></a>
Content-Type: text/plain; charset="utf-8"

On Sun, Jun 8, 2014 at 7:01 PM, Barry Smith <a moz-do-not-send="true" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> wrote:

</pre>
                <blockquote type="cite">
                  <pre>  Mark,

   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.
</pre>
                </blockquote>
                <pre>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.


</pre>
                <blockquote type="cite">
                  <pre>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?

</pre>
                </blockquote>
                <pre>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a moz-do-not-send="true" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/e660c932/attachment.html" target="_blank"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140609/e660c932/attachment.html></a>

------------------------------

Subject: Digest Footer

_______________________________________________
HPGMG-Forum mailing list
<a moz-do-not-send="true" href="mailto:HPGMG-Forum@hpgmg.org" target="_blank">HPGMG-Forum@hpgmg.org</a>
<a moz-do-not-send="true" href="https://hpgmg.org/lists/listinfo/hpgmg-forum" target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>


------------------------------

End of HPGMG-Forum Digest, Vol 3, Issue 6
*****************************************

</pre>
                <span class="HOEnZb"><font color="#888888"> </font></span></blockquote>
              <span class="HOEnZb"><font color="#888888"> <br>
                  <div>-- <br>
                    <b style="color:blue">Dr. E. Theodore L. Omtzigt</b><br>
                    CEO and Founder<br>
                    Stillwater Supercomputing, Inc.<br>
                    office US: EST <a moz-do-not-send="true"
                      href="tel:%28617%29%20314%206424"
                      value="+16173146424" target="_blank">(617) 314
                      6424</a>, PST <a moz-do-not-send="true"
                      href="tel:%28415%29%20738%207387"
                      value="+14157387387" target="_blank">(415) 738
                      7387</a><br>
                    mobile US: <a moz-do-not-send="true"
                      href="tel:%2B1%20916%20296-7901"
                      value="+19162967901" target="_blank">+1 916
                      296-7901</a><br>
                    mobile EU: <a moz-do-not-send="true"
                      href="tel:%2B31%206%20292%20000%2050"
                      value="+31629200050" target="_blank">+31 6 292 000
                      50</a><br>
                    3941 Park Drive, Suite 20-354<br>
                    El Dorado Hills, CA 95762<br>
                    USA</div>
                </font></span></div>
            <br>
            _______________________________________________<br>
            HPGMG-Forum mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a><br>
            <a moz-do-not-send="true"
              href="https://hpgmg.org/lists/listinfo/hpgmg-forum"
              target="_blank">https://hpgmg.org/lists/listinfo/hpgmg-forum</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <b style="color:blue">Dr. E. Theodore L. Omtzigt</b><br>
      CEO and Founder<br>
      Stillwater Supercomputing, Inc.<br>
      office US: EST (617) 314 6424, PST (415) 738 7387<br>
      mobile US: +1 916 296-7901<br>
      mobile EU: +31 6 292 000 50<br>
      3941 Park Drive, Suite 20-354<br>
      El Dorado Hills, CA 95762<br>
      USA</div>
  </body>
</html>