<div dir="ltr"><div dir="ltr">Hi,<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 27, 2019 at 5:48 PM Ullmann, Thomas <<a href="mailto:thomas.ullmann@mpibpc.mpg.de">thomas.ullmann@mpibpc.mpg.de</a>> wrote:</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"><br>
<br>
1081 /home/tullman/GROMACS/<a href="http://gromacs.release-5-X.my/src/gromacs/simd/impl_x86_avx_256/impl_x86_avx_256_simd_double.h:60:9" rel="noreferrer" target="_blank">gromacs.release-5-X.my/src/gromacs/simd/impl_x86_avx_256/impl_x86_avx_256_simd_double.h:60:9</a>: error: constructor does not initialize these fields: simdInternal_ [cppcoreguidelines-pro-type-member-init,-warnings-as-errors]<br>
1082 SimdDouble() {}<br>
1083 ^<br>
<br></blockquote><div><br></div><div>That could be a new version of clang being more picky, or using a different format for the internal storage of the SIMD type.</div><div><br></div><div>However, for C++ it's a very good practice not to define variables until you actually need them. If you only need the variable inside a loop, just define it there :-) That way we are guaranteed never to have an uninitialized variable, and also that it won't have any old value we forgot about. If anything, should we start looking into the warning, one potential solution might just be to prohibit declaring uninitialized SIMD vars :-)</div><div> </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">
OK, I understand and I do not intend to touch the SIMD module itself. I wrote the SIMD code for the linear algebra on<br>
my matrix classes for use in core gmx, that is in the lambda dynamics module, which (hopefully) will be run very frequently<br>
and would then of course consume valuable resources on supercomputers. The functional mode analysis can just also profit<br>
from this code ...<br></blockquote><div><br></div><div>Sure, but "hopefully" is the key word there ;-) The reason for my comment is that there's no such thing as a free lunch: If the amount of work required to get a normal clean patch to compile clean and have people happy about it is "N", you might very well have to spend "5N" to get the same code committed as SIMD. For example: Every single test you write will also have to consider and test the different SIMD widths, and no changes will be able to go in until the handful of us who are familiar with SIMD (mostly me, Roland, Berk and Mark) have time to go through the code in detail.</div><div><br></div><div>Doing it without SIMD now won't prevent you from adding that later - and then everyone will find it much easier to understand, because it's just a SIMD version of well-documented and well-tested code already working :-)</div><div><br></div><div><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"><br>
<br>
<a href="https://gerrit.gromacs.org/#/c/3277/50/docs/reference-manual/analysis/functional-mode-analysis.rst" rel="noreferrer" target="_blank">https://gerrit.gromacs.org/#/c/3277/50/docs/reference-manual/analysis/functional-mode-analysis.rst</a><br>
<br></blockquote><div><br></div><div>Will have to get back on that later - difficult to check on the phone :-)</div><div><br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div></div>