<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.gmail-m-4031041551384275349msolistparagraph, li.gmail-m-4031041551384275349msolistparagraph, div.gmail-m-4031041551384275349msolistparagraph
{mso-style-name:gmail-m_-4031041551384275349msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Maybe a starting point would be to define a standardized interface that would interact with a suite of tools that helps you determine optimized strategies for that cluster (automatically) – (and by tools, I don’t mean that they all support
a text editor and a scripting tool). So a sort of “autoconfigure” process.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"Peter St. John" <peter.st.john@gmail.com><br>
<b>Date: </b>Monday, September 20, 2021 at 2:43 PM<br>
<b>To: </b>Jim Lux <james.p.lux@jpl.nasa.gov><br>
<b>Cc: </b>"beowulf@beowulf.org" <beowulf@beowulf.org><br>
<b>Subject: </b>[EXTERNAL] Re: [Beowulf] Rant on why HPC isn't as easy as I'd like it to be.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My dream is to use some sort of optimization software (I would try Genetic Programing say) with a heterogeneous cluster (of mixed fat and light nodes, even different network topologies in sub-clusters) to determine the optimal configuration
and optimal running parameters in an application domain for itself. I have published (to a limited audience) on Genetic Algorithms optimizing themselves recursively (there is converge behaviour).
<o:p></o:p></p>
<div>
<p class="MsoNormal">Peter<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 20, 2021 at 2:28 PM Lux, Jim (US 7140) via Beowulf <<a href="mailto:beowulf@beowulf.org">beowulf@beowulf.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The recent comments on compilers, caches, etc., are why HPC isn’t a bigger deal. The infrastructure today is reminiscent of what I used in the 1970s on a big CDC or Burroughs or
IBM machine, perhaps with a FPS box attached. <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I prepare a job, with some sort of job control structure, submit it to a batch queue, and get my results some time later. Sure, I’m not dropping off a deck or tapes, and I’m not
getting green-bar paper or a tape back, but really, it’s not much different – I drop a file and get files back either way.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">And just like back then, it’s up to me to figure out how best to arrange my code to run fastest (or me, wall clock time, but others it might be CPU time or cost or something else)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It would be nice if the compiler (or run-time or infrastructure) figured out the whole “what’s the arrangement of cores/nodes/scratch storage for this application on this particular
cluster”. <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I also acknowledge that this is a “hard” problem and one that doesn’t have the commercial value of, say, serving the optimum ads to me when I read the newspaper on line.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
Yeah, it’s not that hard to call library routines for matrix operations, and to put my trust in the library writers – I trust them more than I trust me to find the fastest linear equation solver, fft, etc. – but so far, the next level of abstraction up – “how
many cores/nodes” is still left to me, and that means doing instrumentation, figuring out what the results mean, etc.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Beowulf <<a href="mailto:beowulf-bounces@beowulf.org" target="_blank">beowulf-bounces@beowulf.org</a>> on behalf of "<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>" <<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>><br>
<b>Reply-To: </b>Jim Lux <<a href="mailto:james.p.lux@jpl.nasa.gov" target="_blank">james.p.lux@jpl.nasa.gov</a>><br>
<b>Date: </b>Monday, September 20, 2021 at 10:42 AM<br>
<b>To: </b>Lawrence Stewart <<a href="mailto:stewart@serissa.com" target="_blank">stewart@serissa.com</a>>, Jim Cownie <<a href="mailto:jcownie@gmail.com" target="_blank">jcownie@gmail.com</a>><br>
<b>Cc: </b>Douglas Eadline <<a href="mailto:deadline@eadline.org" target="_blank">deadline@eadline.org</a>>, "<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>" <<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>><br>
<b>Subject: </b>Re: [Beowulf] [EXTERNAL] Re: Deskside clusters</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Beowulf <<a href="mailto:beowulf-bounces@beowulf.org" target="_blank">beowulf-bounces@beowulf.org</a>> on behalf of Lawrence Stewart <<a href="mailto:stewart@serissa.com" target="_blank">stewart@serissa.com</a>><br>
<b>Date: </b>Monday, September 20, 2021 at 9:17 AM<br>
<b>To: </b>Jim Cownie <<a href="mailto:jcownie@gmail.com" target="_blank">jcownie@gmail.com</a>><br>
<b>Cc: </b>Lawrence Stewart <<a href="mailto:stewart@serissa.com" target="_blank">stewart@serissa.com</a>>, Douglas Eadline <<a href="mailto:deadline@eadline.org" target="_blank">deadline@eadline.org</a>>, "<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>"
<<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>><br>
<b>Subject: </b>Re: [Beowulf] [EXTERNAL] Re: Deskside clusters</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Well said. Expanding on this, caches work because of both temporal locality and
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">spatial locality. Spatial locality is addressed by having cache lines be substantially<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">larger than a byte or word. These days, 64 bytes is pretty common. Some prefetch schemes, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">like the L1D version that fetches the VA ^ 64 clearly affect spatial locality. Streaming <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">prefetch has an expanded notion of “spatial” I suppose!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">What puzzles me is why compilers seem not to have evolved much notion of cache management. It <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">seems like something a smart compiler could do. Instead, it is left to Prof. Goto and the folks<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">at ATLAS and BLIS to figure out how to rewrite algorithms for efficient cache behavior. To my<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">limited knowledge, compilers don’t make much use of PREFETCH or any non-temporal loads and stores<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">either. It seems to me that once the programmer helps with RESTRICT and so forth, then compilers could perfectly well dynamically move parts of arrays around to maximize cache use.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-L<o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph"> <o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph">I suspect that there’s enough variability among cache implementation and the wide variety of algorithms that might use it that writing a smart-enough compiler is “hard” and “expensive”.<o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph"> <o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph">Leaving it to the library authors is probably the best “bang for the buck”.
<o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph"> <o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph"> <o:p></o:p></p>
<p class="gmail-m-4031041551384275349msolistparagraph"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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://urldefense.us/v3/__https:/beowulf.org/cgi-bin/mailman/listinfo/beowulf__;!!PvBDto6Hs4WbVuu7!dg1ffH4LrGCTGLtwO3vupHnNuPn0p8vLtPB1lGW8oEgUjvZDwI-Rw_pmrBr9p3pcqpXXQns$" target="_blank">
https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>