<div dir="ltr">No, HPCG  is all memory bandwidth. <div>You can see this old presentation where GPUs with basically no double precision, perform on par with others with 10x performance.</div><div><br></div><div><a href="http://www.hpcg-benchmark.org/downloads/sc14/HPCG_BOF.pdf">http://www.hpcg-benchmark.org/downloads/sc14/HPCG_BOF.pdf</a><br></div><div><br></div><div><div class="gmail-page" title="Page 7"><div class="gmail-section" style="color:rgb(0,0,0)">There were more examples during recent HPCG BOFs ( but I can't find the pdf online, if you want I can send them to you).</div><div class="gmail-section" style="color:rgb(0,0,0)">For example, if you look at the specs of a K80 ( 2xGK210 , <span style="color:rgb(34,34,34)">1.4TF DP and 384 bit memory bus  at 5GHz</span> ) and M40 (GM200, 0.2TF DP and <span style="color:rgb(34,34,34)">384 bit memory bus  at 6GHz), you may think that the K80 will much faster.</span> Exactly the opposite, and the results scale perfectly with memory bandwidth.</div><div class="gmail-section" style="color:rgb(0,0,0)"><br></div><b>1 x K80 (2 GK210 GPUs), ECC enabled, clk=875</b><br>2x1x1 process grid<br>256x256x256 local domain<br>SpMV = 49.1 GF ( 309.1 GB/s Effective) 24.5 GF_per ( 154.6 GB/s Effective) SymGS = 62.2 GF ( 480.2 GB/s Effective) 31.1 GF_per ( 240.1 GB/s Effective) total = 58.7 GF ( 445.3 GB/s Effective) 29.4 GF_per ( 222.7 GB/s Effective) final = 55.1 GF ( 417.5 GB/s Effective) 27.5 GF_per ( 208.8 GB/s Effective)<br><br><b>2 x M40 (2 GM200 GPUs), ECC enabled, clk=1114</b><br>2x1x1 process grid<br>256x256x256 local domain<br>SpMV = 69.4 GF ( 437.2 GB/s Effective) 34.7 GF_per ( 218.6 GB/s Effective) SymGS = 83.7 GF ( 645.7 GB/s Effective) 41.8 GF_per ( 322.8 GB/s Effective) total = 79.6 GF ( 603.7 GB/s Effective) 39.8 GF_per ( 301.9 GB/s Effective) final = 74.2 GF ( 562.7 GB/s Effective) 37.1 GF_per ( 281.4 GB/s Effective)</div><div class="gmail-page" title="Page 7"><br></div><div class="gmail-page" title="Page 7"><div class="gmail-section" style="color:rgb(0,0,0)">Regarding Linpack, on CPU systems  the trailing matrix update is slow, you can hide all the network traffic with the look-ahead if you have a decent network (most CPU-only systems on the list are not real  HPC systems, just some OEMs stuffing the list with cloud systems with very poor network).</div><div class="gmail-section" style="color:rgb(0,0,0)">On accelerated systems ( for example GPU), network becomes really critical.</div><div class="gmail-section" style="color:rgb(0,0,0)"><br></div><div class="gmail-section" style="color:rgb(0,0,0)">Now, memory bw is the real limitation in most HPC workloads, so if I had to select a system, I would care more about memory bw than HPL.</div><div class="gmail-section" style="color:rgb(0,0,0)"><br></div><div class="gmail-section" style="color:rgb(0,0,0)">M</div></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 21, 2022 at 11:51 AM Prentice Bisbal via Beowulf <<a href="mailto:beowulf@beowulf.org">beowulf@beowulf.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>M, <br>
    </p>
    <p>Isn't it more accurate to say that HPCG measures the whole system
      more realistically, and memory bandwidth happens to be the "rate
      limiting step" in just about all architectures? Even with LINPACK,
      which should be CPU-bound, the Top500 list shows that HPL results
      are affected by the network. For example, there's this article
      which is a bit old, but I think still applies (doing the same
      analysis on the current top500 list is on my to-do list,
      actually): <br>
    </p>
    <p><a href="https://www.nextplatform.com/2015/07/20/ethernet-will-have-to-work-harder-to-win-hpc/" target="_blank">https://www.nextplatform.com/2015/07/20/ethernet-will-have-to-work-harder-to-win-hpc/</a><br>
    </p>
    <pre cols="72"></pre>
    <div>On 3/18/22 8:34 PM, Massimiliano Fatica
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">HPCG measures memory bandwidth, the FLOPS
        capability of the chip is completely irrelevant.
        <div>Pretty much all the vendor implementations reach very
          similar efficiency if you compare them to the available memory
          bandwidth.</div>
        <div>There is some effect of the network at scale, but you need
          to have a really large  system to see it in play.</div>
        <div><br>
        </div>
        <div>M</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, Mar 18, 2022 at 5:20
          PM Brian Dobbins <<a href="mailto:bdobbins@gmail.com" target="_blank">bdobbins@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">
            <div><br>
            </div>
            <div>Hi Jorg,<br>
            </div>
            <div><br>
            </div>
            <div>  We (NCAR - weather/climate applications) tend to find
              that HPCG more closely tracks the performance we see from
              hardware than Linpack, so it definitely is of interest and
              watched, but our procurements tend to use actual code that
              vendors run as part of the process, so we don't 'just' use
              published HPCG numbers.  Still, I'd say it's still very
              much a useful number, though.</div>
            <div><br>
            </div>
            <div>  As one example, while I haven't seen HPCG numbers for
              the MI250x accelerators, Prof. Matuoka of RIKEN tweeted
              back in November that he anticipated that to score around
              0.4% of peak on HPCG, vs 2% on the NVIDIA A100 (while the
              A64FX they use hits an impressive 3%):</div>
            <div><a href="https://twitter.com/ProfMatsuoka/status/1458159517590384640" target="_blank">https://twitter.com/ProfMatsuoka/status/1458159517590384640</a></div>
            <div><br>
            </div>
            <div>  Why is that relevant?  Well, <i>on paper</i>, the
              MI250X has ~96 TF FP64 w/ Matrix operations, vs 19.5 TF on
              the A100.  So, 5x in theory, but Prof Matsuoka anticipated
              a ~5x differential in HPCG, <i>erasing</i> that
              differential.  Now, surely <i>someone</i> has HPCG
              numbers on the MI250X, but I've not yet seen any.  Would
              love to know what they are.  But absent that information I
              tend to bet Matsuoka isn't far off the mark.</div>
            <div><br>
            </div>
            <div>  Ultimately, it may help knowing more about what kind
              of applications you run - for memory bound CFD-like codes,
              HPCG tends to be pretty representative.  <br>
            </div>
            <div><br>
            </div>
            <div>  Maybe it's time to update the saying that 'numbers
              never lie' to something more accurate - 'numbers never
              lie, but they also rarely tell the whole story'.</div>
            <div><br>
            </div>
            <div>  Cheers,</div>
            <div>  - Brian</div>
            <div><br>
            </div>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Fri, Mar 18, 2022 at
              5:08 PM Jörg Saßmannshausen <<a href="mailto:sassy-work@sassy.formativ.net" target="_blank">sassy-work@sassy.formativ.net</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dear
              all,<br>
              <br>
              further the emails back in 2020 around the HPCG benchmark
              test, as we are in <br>
              the process of getting a new cluster I was wondering if
              somebody else in the <br>
              meantime has used that test to benchmark the particular
              performance of the <br>
              cluster. <br>
              From what I can see, the latest HPCG version is 3.1 from
              August 2019. I also <br>
              have noticed that their website has a link to download a
              version which <br>
              includes the latest A100 GPUs from nVidia. <br>
              <a href="https://www.hpcg-benchmark.org/software/view.html?id=280" rel="noreferrer" target="_blank">https://www.hpcg-benchmark.org/software/view.html?id=280</a><br>
              <br>
              What I was wondering is: has anybody else apart from
              Prentice tried that test <br>
              and is it somehow useful, or does it just give you another
              set of numbers?<br>
              <br>
              Our new cluster will not be at the same league as the
              supercomputers, but we <br>
              would like to have at least some kind of handle so we can
              compare the various <br>
              offers from vendors. My hunch is the benchmark will
              somehow (strongly?) depend <br>
              on how it is tuned. As my former colleague used to say: I
              am looking for some <br>
              war stories (not very apt to say these days!).<br>
              <br>
              Either way, I hope you are all well given the strange new
              world we are living <br>
              in right now.<br>
              <br>
              All the best from a spring like dark London<br>
              <br>
              Jörg<br>
              <br>
              <br>
              <br>
              _______________________________________________<br>
              Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a>
              sponsored by Penguin Computing<br>
              To change your subscription (digest mode or unsubscribe)
              visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
            </blockquote>
          </div>
          _______________________________________________<br>
          Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a>
          sponsored by Penguin Computing<br>
          To change your subscription (digest mode or unsubscribe) visit
          <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
</blockquote></div>