<div dir="ltr">For all developers out there: RFC.<br><br>I hope you do realize that the issues we are discussing are not if-s and when-s and you'll face them as soon as you want to
add/remove/change a compiler flag!<br><br><div></div><br><div class="gmail_extra">On Tue, Feb 5, 2013 at 8:30 PM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="im">On Tue, Feb 5, 2013 at 1:48 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> 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">
<div>
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">Hi,<br>
<br>
</div><div class="im">
<div class="gmail_quote">Let me state this early enough:<br>
- the concerns I raised are related to *usability* and not some standard common practice defines the current compiler flag setup and behaviour;<br>
- I consider the current setup safe and consistent for anyone who dos not care about compiler flags, but extremely confusing, a potential performance concern, and error prone as well for those who want to do *anything* with compiler flags. Just think through
how will you explain to an average, rather inexperienced GROMACS user to change a default flag to something else.<br>
</div>
</div><div class="gmail_quote"><div><div class="im"><br>
On Sun, Feb 3, 2013 at 1:53 AM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>On Sat, Feb 2, 2013 at 5:42 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi,</span>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">With the compiler flag handling changed between beta3 and final, now it is completely impossible to check or modify compiler flags we generate.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">I might have missed the discussion on this during code review, but I simply consider this a bug. It is pretty much impossible to know what compiler flags are being used - at least not at build time, not
even by looking at the cache, and not without first compiling a binary and checking the "-version" output.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">Not only that this is a rather annoying, making it impossible to change the default compiler options is a very naive behavior.
</div>
</div>
</div>
</blockquote>
</div>
<div>You need to set GMX_SKIP_DEFAULT_CFLAGS. This lets you overwrite and see what would be appended.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div class="im"><div>Sorry, but that does not answer my questions/concerns. Moreover, GMX_SKIP_DEFAULT_CFLAGS seems to me an awkward workaround. First of all, there is no intuitive way to figure out how to do what many moderately advanced user will want accomplish at some
point: simply reviewing and changing the compiler flags.<br>
Secondly, the name of the variable suggests nothing about the fact that this is the only way to review/edit the flags and even if some user happens to magically figure it out (which I highly doubt), a cluttered dump of the flags "skipped" is even worse than
providing a "configure-compatible" behaviour, i.e with configure everything is in the config.log while we have only the CMake defaults (=inferior), with configure you override everything, in our case some flags get overridden other don't.<br>
<br>
</div></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div><br>
</div><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px">Additionally, there is another issue with the bove example: manually passing CMAKE_C_FAGLS_RELEASE will overwrite the default release flags (-O3 -DNDEBUG). This leads to another issue: passing any additional release
flag will lead to -O2 being used as this is the default with most compilers (and -O3 get overridden). Consequently, if one wants to *append* and optimization flag, this can only be done post-configure by modifying the cache, but not during configure which
goes against the principle we tried to adhere to that users should be able to flexibly configure GROMACS by using a single command.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div class="im">
<div>O3 is set by cmake not by us - and it behaves as cmake developers think it should behave. Look at the redmine issues for the details.</div>
</div></div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div><div class="im"><div>If you consider this for a second you will probably agree: it's pretty much irrelevant (from the user's point of view) whether a flag is CMake default or custom GROMACS one. In fact, as we are very much concerned about performance and many of the flags
we set serve this goal, I would argue that the optimization level should perhaps be controlled by us and not CMake - especially that CMake happily overwrites the non-hidden part of CMAKE_C_FAGLS_RELEASE thus throwing out the *very important* -O3. This will
result in falling back to -O2 (the default with most compilers) which will lead to significant performance loss.<br>
</div></div><div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div><br>
</div><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px">I think the above issues need fixing asap, preferably by 4.6.1, but I'm not familiar with the code, so I can't suggest a concrete solution.</div>
</div>
</div>
</blockquote>
</div></div><div class="im">
<div>I disagree. Everything works the way as has been discussed in redmine. We shoudn't change the behaviour after a release.</div>
</div></div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div><div class="im"><div>Sorry, but that's not entirely true. #1038 was mostly concerned about the CPU acceleration detection not working consistently and about monolithic vs modular CFLAGS which is not what I am talking about. Unfortunately I did not have time neither to comment
on 1040 nor to review the change before it got merged (rather hastily, after only 12h by the author himself). Note that 1040 which was talking about usability and consistency and while the latter has improved, the former has IMO gotten worse.
<br>
<br>
<br>
<div>To conclude, I would be OK with the current behaviour if certain thing were possible or less awkward to do, e.g.:<br>
</div>
<div>- reviewing compiler flags used at *configure-time*;<br>
</div>
<div>- adding compiler flags;<br>
</div>
<div>- removing/overriding compiler flags;<br></div></div></div></div></div></div></div></blockquote><div>Look at redmine for the details why any implementation, which allows overwrite and be consistent between Gromacs and cmake flags, would have been too complicated tol make it into 4.6.</div>
</div></div></div></blockquote><div><br></div><div>I'll have a look at the discussion, but I'll need quite some time for that as it very lengthy and contains a long, slightly unrelated, debate.<br><br></div><div>Note that I'm not talking about some magic override, but simply the ability to go to the flags and remove e.g. the "-ip" icc flag which I know that it can in some cases cause performance regression.<br>
<br>In my eyes, reviewing and changing flags is much more important than the consistency of acceleration flags across cmake reruns, that's why I find it unfortunate that the build system got crippled in an attempt to fix that issue. Of course, I am biased, but putting aside the fact that I will suffer from this build system "behaviour regression", I think many sysadmins and other advanced users will also be scratching their heads.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>
</div>
<div>and adding or overriding should be possible through a single command-line invocation.<br>
<br>
More concretely IMO what we need is:<br>
- A summary printed or at least some read-only advanced variables so that one does not need to run e.g "mdrun -version" to know what flags are used;<br></div></div></div></div></div></div></blockquote></div><div>
I was (and still am) all for the summary. I really liked Teemu's start of it. But it got cut because of time. Not sure it would be a good idea to print just the flags without having a full summary. I think having read-only variables is very confusing.</div>
</div></div></div></blockquote><div><br></div><div>I see your point, but you have yet to reply to my criticism on the fact that <i>it is impossible to at least check what flags are being used</i> and that is a major flaw.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>
</div>
<div><br>
- An intuitive and consistent way to add/change the flags, what the user wants is simple, but currently requires a set of strange steps: enable skipping GROMACS flags, copy the printed flags, remove cache, re-run cmake with the copied flags.<br>
</div></div></div></div></div></div></blockquote></div><div>No need to remove the cache.</div></div></div></div></blockquote><div><br></div><div>Fine, remove that step, but you've to add two more instead:<br>- check default CMake flags;<br>
- re-add those when setting flags manually<br></div><div><br></div><div>Again, I would very much appreciate of you or others developers would actually comment on the issue in question: the usability concerns around this rather long, complicated, and error-prone set of steps required just to change a flag -Foo to -Bar.<br>
<br></div><div>Cheers,<br><div>--<br>Szilárd</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div>
<div>Roland</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><div>
It might be a good idea to override everything or nothing regardless whether it's GROMACS or CMake flags.<br>
<br>
</div>
<div>Cheers,<br>
Szilard<br>
</div>
<br>
</div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Roland </div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">Cheers,</div><span class=""><font color="#888888">
<span><font color="#888888">
<div>
<div>--<br>
Szilárd</div>
</div>
</font></span></font></span></div>
<span><font color="#888888"></font></span></div>
<span><font color="#888888"></font></span></blockquote>
</div><div class="im">
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">
cmb.ornl.gov</a><br>
<a href="tel:865-241-1537" value="+18652411537" target="_blank">865-241-1537</a>, ORNL PO BOX 2008 MS6309 </font></span></div></div>
</div>
<br></div><div class="im"><span><font color="#888888">
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">
gmx-developers-request@gromacs.org</a>.<br>
</font></span></div></blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote></div><br><br clear="all"><div class="im"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</div></div></div>
<br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>