<div dir="ltr">Thanks so much for your replies, Erik & Roland!<div><br></div><div>I've a followup question:<div><br></div><div>By default NRPy+/SENR codes store all gridfunctions in a 1D array, which the compiler tends to treat very conservatively. E.g., to access gxx and write to gxx_rhs, you might see something like (without compiler intrinsics for clarity):<br></div><div><br></div><div>const double gxx = in_gfs[IDX4(GXX,i,j,k)];</div><div><br></div><div>...</div><div><br></div><div>rhs_gfs[IDX4(GXX,i,j,k)] = blah;</div><div><br></div><div>respectively.</div><div><br></div><div>This 4D data type resulted in "vectorization cannot be performed because of possible data dependencies" types of messages, because all gridfunctions were being read from one 1D array and written to another 1D array. As a workaround and to keep the 1D array style *outside* the RHS eval function, I passed the start address of each gridfunction to the RHS function separately, using the *restrict keyword. </div><div><br></div><div>My question is, should this workaround be necessary, or is there another, more straightforward approach?</div><div><br clear="all"><div><div dir="ltr" class="m_5790956014382495057gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px">-Zach</div><div style="font-size:12.8px"><br></div><span style="font-size:12.8px">* * *</span><br style="font-size:12.8px"><span style="font-size:12.8px">Prof. Zachariah Etienne</span><br style="font-size:12.8px"><div style="font-size:12.8px">West Virginia University</div><div><font color="#0000ee"><u><a href="https://math.wvu.edu/~zetienne/" target="_blank">https://math.wvu.edu/~zetienne/</a></u></font></div><div><a href="https://blackholesathome.net" style="font-size:12.8px" target="_blank">https://blackholesathome.net</a><br></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2019 at 11:45 AM Haas, Roland <<a href="mailto:rhaas@illinois.edu" target="_blank">rhaas@illinois.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
just to stoke your paranoia :-)<br>
<br>
Erik's comment of checking the disassembled output is definitely the<br>
right way to go.<br>
<br>
I kind of vaguely remember having heard that, at least for some<br>
version of some compilers, once you use intrinsics the compiler will no<br>
longer try to auto-vectorize the code (presumably the function) since<br>
it takes you using intrinsics as an indication that you know what you<br>
are doing.<br>
<br>
Yours,<br>
Roland<br>
<br>
> Hi Erik,<br>
> <br>
> Thanks for your reassuring reply.<br>
> <br>
> > Did you look at the generated code? Try calling the compiler with the <br>
> "-S" option to get assembler output, or use "objdump -d" to disassemble the<br>
> object file. You should see lots of "ymms" mentioned in your memory access<br>
> and arithmetic operations.<br>
> <br>
> Yep, as I mentioned, the `-S -g` commented assembler indeed did output lots<br>
> of "ymms" in the innermost loop. Also, the annotated assembler on the<br>
> innermost loop gave precisely the same remark about not being able to<br>
> vectorize an operation:<br>
> <br>
> # optimization report<br>
> # LOOP WITH USER VECTOR INTRINSICS<br>
> # %s was not vectorized: operation cannot be vectorized<br>
> # VECTOR TRIP COUNT IS ESTIMATED CONSTANT<br>
> <br>
> -Zach<br>
> <br>
> * * *<br>
> Prof. Zachariah Etienne<br>
> West Virginia University<br>
> *<a href="https://math.wvu.edu/~zetienne/" rel="noreferrer" target="_blank">https://math.wvu.edu/~zetienne/</a> <<a href="https://math.wvu.edu/~zetienne/" rel="noreferrer" target="_blank">https://math.wvu.edu/~zetienne/</a>>*<br>
> <a href="https://blackholesathome.net" rel="noreferrer" target="_blank">https://blackholesathome.net</a><br>
> <br>
> <br>
> On Tue, Jul 23, 2019 at 11:08 AM Erik Schnetter <<a href="mailto:schnetter@gmail.com" target="_blank">schnetter@gmail.com</a>> wrote:<br>
> <br>
> > Zach<br>
> ><br>
> > The compiler is correct: The intrinsic _mm256_loadu_pd cannot be<br>
> > vectorized because ... it is already vectorized! If you are using<br>
> > intrinsics for vectorization, then the compiler does not need to<br>
> > perform any work.<br>
> ><br>
> > Did you look at the generated code? Try calling the compiler with the<br>
> > "-S" option to get assembler output, or use "objdump -d" to<br>
> > disassemble the object file. You should see lots of "ymms" mentioned<br>
> > in your memory access and arithmetic operations.<br>
> ><br>
> > -erik<br>
> ><br>
> > On Tue, Jul 23, 2019 at 9:35 AM Zach Etienne <<a href="mailto:zachetie@gmail.com" target="_blank">zachetie@gmail.com</a>> wrote: <br>
> > ><br>
> > > Hi all,<br>
> > ><br>
> > > I used NRPy+ to create a "minimal example" SIMD-intrinsics-enabled PDE <br>
> > solver kernel -- solving the scalar wave equation in 3 spatial dimensions. <br>
> > ><br>
> > > With AVX256+FMA intrinsics, neither Intel nor GNU compilers report <br>
> > success at fully vectorizing the RHS eval loop. E.g., the Intel compiler<br>
> > yields the cryptic message when compiling the innermost loop: <br>
> > ><br>
> > > remark #15310: loop was not vectorized: operation cannot be <br>
> > vectorized [ ScalarWave/ScalarWave_RHSs-SIMD.h(31,52) ] <br>
> > ><br>
> > > The line it's referring to has to do with loading data from memory <br>
> > _mm256_loadu_pd(&a). <br>
> > ><br>
> > > The entire source code is attached to this email, and I've been <br>
> > compiling using <br>
> > ><br>
> > > icc -restrict -align -qopenmp -xHost -O2 -qopt-report=5 <br>
> > -qopt-report-phase ipo -qopt-report-phase vec -vec-threshold1<br>
> > -qopt-prefetch=4 ScalarWave_Playground-SIMD.c -o ScalarWave_Playground-SIMD <br>
> > ><br>
> > > for Intel 19, and for GNU (gcc 9):<br>
> > ><br>
> > > gcc -fsimd-cost-model=unlimited -Ofast -fopenmp -march=native <br>
> > ScalarWave_Playground-SIMD.c -fopt-info-vec-optimized-missed -o<br>
> > ScalarWave_Playground-SIMD -lm <br>
> > ><br>
> > > When I look at the Intel-generated annotated assembly of the innermost <br>
> > RHS loop (using icc -S -g -restrict -align -qopenmp -xHost -O2<br>
> > -qopt-report=5 -qopt-report-phase ipo -qopt-report-phase vec<br>
> > -vec-threshold1 -qopt-prefetch=4 ScalarWave_Playground-SIMD.c), I see many<br>
> > 256-bit "ymmX"'s and corresponding instructions that seem to be consistent<br>
> > with the *math* intrinsics. I can't decipher much beyond that, though.<br>
> > Notably I didn't see any assembler instructions that look like<br>
> > _mm256_loadu_pd(). <br>
> > ><br>
> > > I fiddled around a bit with what goes inside the _mm256_loadu_pd(), just <br>
> > to see what might be causing the cryptic remark above. I found that if I<br>
> > remove dependence on the innermost loop variable "i0" on certain (obviously<br>
> > this would break the functionality, but the compiler doesn't care), then it<br>
> > is capable of vectorizing that loop. <br>
> > ><br>
> > > Note that the version of the code that does not use intrinsics is about <br>
> > 1.8x slower with either compiler, so I think intrinsics are providing some<br>
> > good benefit. However, I am discouraged by the compiler telling me that the<br>
> > inner loop cannot be fully vectorized. <br>
> > ><br>
> > > Any tips would be greatly appreciated!<br>
> > ><br>
> > > -Zach<br>
> > ><br>
> > > * * *<br>
> > > Prof. Zachariah Etienne<br>
> > > West Virginia University<br>
> > > <a href="https://math.wvu.edu/~zetienne/" rel="noreferrer" target="_blank">https://math.wvu.edu/~zetienne/</a><br>
> > > <a href="https://blackholesathome.net" rel="noreferrer" target="_blank">https://blackholesathome.net</a><br>
> > > _______________________________________________<br>
> > > performanceoptimization-wg mailing list<br>
> > > <a href="mailto:performanceoptimization-wg@einsteintoolkit.org" target="_blank">performanceoptimization-wg@einsteintoolkit.org</a><br>
> > > <br>
> > <a href="http://lists.einsteintoolkit.org/mailman/listinfo/performanceoptimization-wg" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/performanceoptimization-wg</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Erik Schnetter <<a href="mailto:schnetter@gmail.com" target="_blank">schnetter@gmail.com</a>><br>
> > <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="noreferrer" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a><br>
> > <br>
<br>
<br>
<br>
-- <br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://keys.gnupg.net" rel="noreferrer" target="_blank">http://keys.gnupg.net</a>.<br>
</blockquote></div></div></div>