<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    For von Neumann architectures the resources that actually support
    compute state should be the quantification of 'processor'. <br>
    <br>
    In hyperthreaded architectures, there is duplication of the
    front-end (decode to dispatch), and times-slicing on the back-end
    (functional units) to better utilize the silicon. <br>
    <br>
    In many-core architectures, which have very long pipelines to
    memory, the front-end is duplicated on the state side (IP, control
    registers, etc.) so that the hardware can multiplex these threads to
    fill the memory pipelines. <br>
    <br>
    The reason this is important is that these architectures are
    designed to be 'used' that way. Otherwise stated, the queuing that
    goes on in the hardware is optimized to 'compute' the optimal
    resource utilization only when there is enough concurrency
    available. Secondly, the architecture family is typically designed
    to scale across a spectrum of hardware resource implementations, so
    the only element that is constant is the architecture definition of
    the compute abstraction. If you use that to report machine
    organization you are giving the hardware designers a much better
    guidance on what the optimize for HPC.<br>
    <br>
    <blockquote
      cite="mid:mailman.21.1402239266.23863.hpgmg-forum@hpgmg.org"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">On Jun 7, 2014, at 7:01 PM, "Sam Williams" <a class="moz-txt-link-rfc2396E" href="mailto:swwilliams@lbl.gov"><swwilliams@lbl.gov></a> wrote:

Nominally, there would be a paragraph describing the setup for a figure.
</pre>
      </blockquote>
      <pre wrap="">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.
</pre>
      <blockquote type="cite">
        <pre wrap="">
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 class="moz-txt-link-rfc2396E" href="mailto:bsmith@mcs.anl.gov"><bsmith@mcs.anl.gov></a> wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">
 I submit that even nodes or ?sockets? is actually not completely
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">unambiguous
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">
On Jun 7, 2014, at 5:39 PM, Jeff Hammond <a class="moz-txt-link-rfc2396E" href="mailto:jeff.science@gmail.com"><jeff.science@gmail.com></a>
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">
</pre>
          <blockquote type="cite">
            <pre wrap="">On Sat, Jun 7, 2014 at 3:35 PM, Barry Smith <a class="moz-txt-link-rfc2396E" href="mailto:bsmith@mcs.anl.gov"><bsmith@mcs.anl.gov></a>
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
On Jun 7, 2014, at 5:31 PM, Jeff Hammond <a class="moz-txt-link-rfc2396E" href="mailto:jeff.science@gmail.com"><jeff.science@gmail.com></a>
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
</pre>
              <blockquote type="cite">
                <pre wrap="">On Sat, Jun 7, 2014 at 3:26 PM, Barry Smith <a class="moz-txt-link-rfc2396E" href="mailto:bsmith@mcs.anl.gov"><bsmith@mcs.anl.gov></a>
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">
The use of multicore processor == sockets as the independent
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">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 type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">
</pre>
              </blockquote>
              <pre wrap=""> Yes, but how do we measure power? The actual amount being pulled
</pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">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 type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">
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 wrap="">The last suggestion is obviously the best one since it is the most
general, but I think power is the best choice of independent
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">variable.
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">Most of the other hardware features are bad choices because it is
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">very
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">hard to determine some of these.  What is the clock speed of an
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">Intel
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">socket that does dynamic frequency scaling?  How do you count cores
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">on
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">a GPU?  NVIDIA's core-counting methodology is complete nonsense...

Best,

Jeff


</pre>
                <blockquote type="cite">
                  <pre wrap="">On Jun 7, 2014, at 4:27 PM, Jed Brown <a class="moz-txt-link-rfc2396E" href="mailto:jed@jedbrown.org"><jed@jedbrown.org></a> wrote:

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

The most recent announces the v0.1 release and includes a Kiviat
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">diagram
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">comparing the on-node performance characteristics of CORAL apps
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">and
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">several benchmarks running on Blue Gene/Q.

<a class="moz-txt-link-freetext" href="https://hpgmg.org/2014/06/06/hpgmg-01/">https://hpgmg.org/2014/06/06/hpgmg-01/</a>


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

<a class="moz-txt-link-freetext" href="https://hpgmg.org/2014/05/15/fv-results/">https://hpgmg.org/2014/05/15/fv-results/</a>


We are interested in better ways to collect and present the
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">comparison
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">data as well as any characteristics that you think are important.


In addition to the general principles on the front page, some
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">further
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">rationale is given at:

<a class="moz-txt-link-freetext" href="https://hpgmg.org/why/">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
</pre>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">list:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
_______________________________________________
HPGMG-Forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a>
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                  </blockquote>
                  <pre wrap="">
_______________________________________________
HPGMG-Forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a>
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
                </blockquote>
                <pre wrap="">


--
Jeff Hammond
<a class="moz-txt-link-abbreviated" href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a>
</pre>
              </blockquote>
              <pre wrap="">
</pre>
            </blockquote>
            <pre wrap="">


--
Jeff Hammond
<a class="moz-txt-link-abbreviated" href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a>
</pre>
          </blockquote>
          <pre wrap="">
_______________________________________________
HPGMG-Forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a>
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>
</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
HPGMG-Forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a>
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>

</pre>
      </blockquote>
      <pre wrap="">-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a class="moz-txt-link-rfc2396E" href="https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140608/2678ac7c/attachment.html"><https://hpgmg.org/lists/archives/hpgmg-forum/attachments/20140608/2678ac7c/attachment.html></a>

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

Subject: Digest Footer

_______________________________________________
HPGMG-Forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPGMG-Forum@hpgmg.org">HPGMG-Forum@hpgmg.org</a>
<a class="moz-txt-link-freetext" href="https://hpgmg.org/lists/listinfo/hpgmg-forum">https://hpgmg.org/lists/listinfo/hpgmg-forum</a>


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

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

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