[gmx-developers] hidden compiler flags in 4.6?

Tue Feb 5 22:28:43 CET 2013

On Tue, Feb 5, 2013 at 9:26 PM, Roland Schulz <roland at utk.edu> wrote:

>
>
>
> On Tue, Feb 5, 2013 at 2:58 PM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:
>
>>  For all developers out there: RFC.
>>
>> 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!
>>
> sure. It is even clearly documented in the commit message.
>

Not exactly. The commit message suggests that the new behaviour can give
the user "total control". The problem is that because GROMACS and
CMake-default flags are treated differently, this is not true and as
illustrated before one can end up screwing up performance by not realizing
the implications of this.

>
>>  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.
>>
>>  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.
>>
> That's the problem. It is not that easy. I originally made a more
> complicated suggestion which would have allowed overwrite but it would have
> been very complicated. So please take the time to read everything AND make
> a specific suggestion of how to change it. And also keep in mind that we
> usually don't change behavior after a release.
>

That "AND" is rather demanding. I have raised an issue and the issue is not
rendered irrelevant unless I suggest a specific implementation as solution.

IMHO there isn't much point sticking to a behaviour that causes more
trouble than good. So as much as I love that rule a bug requires a fix and
this behaviour is, in my opinion, (borderline) buggy.

>
>
>>  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.
>>
> That wasn't the only problem. It wasn't consistent at all.
>

Well, not to start a long flaming, ones easy fix (that would have avoided
introducing new issues) would have been as simple as adding the following
statement to the docs: "changing CMake variables and re-configuring is only
supported for [list of variables], in all other cases remove the cache and
re-configure".

>
>
>>
>>>
>>>>    and adding or overriding should be possible through a single
>>>> command-line invocation.
>>>>
>>>> More concretely IMO what we need is:
>>>> - 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;
>>>>
>>>  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.
>>>
>>
>>  I see your point, but you have yet to reply to my criticism on the fact
>> that *it is impossible to at least check what flags are being used* and
>> that is a major flaw.
>>
> Like I said I was hoping for the summary.
>
>
>>   - 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.
>>>>
>>>  No need to remove the cache.
>>>
>>
>>  Fine, remove that step, but you've to add two more instead:
>> - check default CMake flags;
>> - re-add those when setting flags manually
>>
>>  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.
>>
> Please not that it is still better than some other compiler/linker flags
> which can't be changed at all. E.g. OpenMP flags are autodected and can't
> be changed at all (unless you change the cmakelists code). The
>

AFAIK the OpenMP flag was easy to change before the upstream merge (by just
editing the CMAKE_C_FLAGS), not sure where did it get complicated.
Moreover, that's not a great example as if the flag check passes, the
OpenMP flag will most probably be correct so there isn't much point in
changing it.

> same is true for any linker flags (e.g. bug 911). To repeat myself: I
> would have liked to have a solution which would have made overwriting easy
> and which would have contained a summary. But that was the solution which
> seemed best with the available time. Please also note that these bugs are 3
> months old. Everyone had plenty of time to come up with a better solution
> in those 3 months.
>

Here's some nitpicking for the sake of correctness: #1040 was <2 months old
when it got closed (Nov 20 - Jan 10) without ever getting feedback (was not
even requested); moreover the change set that claimed to fix it was not
reviewed properly either. Therefore this major change in build system
behaviour could not be, and probably is still not obvious to most
developers - that's why I started the discussion.

Lastly, let's not treat the issue in a way which implies that just because
nobody had a better implementation at hand - and unfortunately even the
discussion was very limited, I have to admit -, the current solution should
be treated as something that everybody knows of - including its drawbacks
and general implications -, accepts, and should avoid criticizing. That's
especially the case as neither installation guide nor any advanced wiki
page or documentation (at least not that Google knows of:
http://goo.gl/JBokD) describes step-by-step the rather complicated and
fragile process of changing compiler flags.

Cheers,
Szilard

>
> Roland
>
>
>>
>>  Cheers,
>> --
>> Szilárd
>>
>>
>>
>>>
>>>  Roland
>>>
>>>
>>>>    It might be a good idea to override everything or nothing
>>>> regardless whether it's GROMACS or CMake flags.
>>>>
>>>>  Cheers,
>>>> Szilard
>>>>
>>>>
>>>>>  Roland
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>  Cheers,
>>>>>>  --
>>>>>> Szilárd
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>>>>
>>>>>  --
>>>>> gmx-developers mailing list
>>>>> gmx-developers at gromacs.org
>>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>>> Please don't post (un)subscribe requests to the list. Use the
>>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>>
>>> --
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>
>>
>>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> 865-241-1537, ORNL PO BOX 2008 MS6309
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130205/db191e88/attachment.html>