<p dir="ltr">I think the boundary between a final product and the start of a project separates these two view points.<br>
Lately, I short stacks of OReilleys scattered about, off libraries and a second stack of notebooks filled with every command that really did work.<br>
And I think it is fun.<br>
Jonathan</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jun 19, 2018 12:11 PM, "Joe Landman" <<a href="mailto:joe.landman@gmail.com">joe.landman@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br>
<br>
On 6/19/18 2:47 PM, Prentice Bisbal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 06/13/2018 10:32 PM, Joe Landman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm curious about your next gen plans, given Phi's roadmap.<br>
<br>
<br>
On 6/13/18 9:17 PM, Stu Midgley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
low level HPC means... lots of things.  BUT we are a huge Xeon Phi shop and need low-level programmers ie. avx512, careful cache/memory management (NOT openmp/compiler vectorisation etc).<br>
</blockquote>
<br>
I played around with avx512 in my rzf code. <a href="https://github.com/joelandman/rzf/blob/master/avx2/rzf_avx512.c" rel="noreferrer" target="_blank">https://github.com/joelandman/<wbr>rzf/blob/master/avx2/rzf_avx51<wbr>2.c</a> .  Never really spent a great deal of time on it, other than noting that using avx512 seemed to downclock the core a bit on Skylake.<br>
</blockquote>
<br>
If you organize your code correctly, and call the compiler with the right optimization flags, shouldn't the compiler automatically handle a good portion of this 'low-level' stuff? <br>
</blockquote>
<br></div>
I wish it would do it well, but it turns out it doesn't do a good job.   You have to pay very careful attention to almost all aspects of making it simple for the compiler, and then constraining the directions it takes with code gen.<br>
<br>
I explored this with my RZF stuff.  It turns out that with -O3, gcc (5.x and 6.x) would convert a library call for the power function into an FP instruction.  But it would use 1/8 - 1/4 of the XMM/YMM register width, not automatically unroll loops, or leverage the vector nature of the problem.<br>
<br>
Basically, not much has changed in 20+ years ... you annotate your code with pragmas and similar, or use instruction primitives and give up on the optimizer/code generator.<br>
<br>
When it comes down to it, compilers aren't really as smart as many of us would like.  Converting idiomatic code into efficient assembly isn't what they are designed for.  Rather correct assembly.  Correct doesn't mean efficient in many cases, and some of the less obvious optimizations that we might think to be beneficial are not taken. We can hand modify the code for this, and see if these optimizations are beneficial, but the compilers often are not looking at a holistic problem.<div class="quoted-text"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand that hand-coding this stuff usually still give you the best performance (See GotoBLAS/OpenBLAS, for example), but does your average HPC programmer trying to get decent performance need to hand-code that stuff, too?<br>
</blockquote>
<br></div>
Generally, yes.  Optimizing serial code for GPUs doesn't work well. Rewriting for GPUs (e.g. taking into account the GPU data/compute flow architecture) does work well.<div class="quoted-text"><br>
<br>
-- <br>
<br>
Joe Landman<br>
e: <a href="mailto:joe.landman@gmail.com" target="_blank">joe.landman@gmail.com</a><br>
t: @hpcjoe<br></div><div class="elided-text">
w: <a href="https://scalability.org" rel="noreferrer" target="_blank">https://scalability.org</a><br>
g: <a href="https://github.com/joelandman" rel="noreferrer" target="_blank">https://github.com/joelandman</a><br>
l: <a href="https://www.linkedin.com/in/joelandman" rel="noreferrer" target="_blank">https://www.linkedin.com/in/jo<wbr>elandman</a><br>
<br>
______________________________<wbr>_________________<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="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
</div></blockquote></div><br></div>