[gmx-developers] libgromacs vs libgromacs_core?

[Mark Abraham]

On Sat, Sep 28, 2013 at 8:58 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
> On Sat, Sep 28, 2013 at 8:05 PM, Teemu Murtola <teemu.murtola at iki.fi> wrote:
>> Hi,
>>
>> On Sat, Sep 28, 2013 at 6:56 PM, Szilárd Páll <szilard.pall at cbr.su.se>
>> wrote:
>>>
>>> I would like to bring up the topic of keeping mdrun lean and as
>>> dependency-free as possible (for HPC/exotic platforms).
>>>
>>> This has been discussed earlier, but I'm not sure what the decision
>>> was (AFAIK there wasn't any) and what the current direction is. The
>>> two possibilities discussed:
>>> - splitting libgromacs into libgromacs and libgromacs_core (where
>>> mdrun depends only on the latter which is as portable and lightweight
>>> as possible);
>>> - more of a workaround solution: allowing to build a stripped-down
>>> version of libgromacs that mdrun links against; this libgromacs may
>>> still be better called libgromacs_core to allow conflict-free
>>> installation of e.g. full non-MPI build + reduced MPI-enabled mdrun
>>> build in the same location.
>>
>>
>> Just as a remark, the second option is already implemented (very roughly) in
>> https://gerrit.gromacs.org/#/c/2571/. I have nothing against a more
>
> Seeing that commit reminded me of this topic. :)
>
>> elaborate solution, but that requires some concreteness to what would the
>> concrete restrictions be, how to deal with utility code used by both mdrun
>> and tools, and how to actually do the split (technically won't be a problem,
>> but more on the logic level: do we, e.g., want/allow to sacrifice some
>> features of the "full" mdrun in the "reduced" version). The last time this
>
> Indeed, and I was hoping that such concrete aspects of a split will be
> brought up in this discussion - instead of claims of this being a
> non-issue (at least not a timely one).
>
> Having spent only a couple of minutes thinking about what could be
> obviously moved out of a potential libgromacs_core, here are a couple
> of things:
> - use of exceptions: I was going to say that we could make
> libgromacs_core exception-free, but that's probably not going to be a
> popular suggestions; however, outside of libgromacs_core exceptions
> could possibly be used in a more liberal manner.

Make sure you compare the development cost of deploying non-exception
handling of exceptional cases, and the fact that you can no longer use
much/any of the standard C++ libraries at all. That is, you're writing
C again! :-)

In practice, when we follow the stated policy of using exceptions only
for handling exceptional cases, they'll be shortly followed by a fatal
error, when originally thrown in mdrun. The relevant case is whether
there is a significant run-time penalty when the normal execution path
is followed, and that we will have to measure when we reach that
point. Early implementations sucked a bit here, I gather. Still, I am
not yet persuaded that it should be our role to cater for the least
common denominator of all HPC compilers, even if we can find out what
the behaviour of their output code is. Someone who's produced
super-fast hardware that is dependent on a crap compiler has produced
a mediocre machine. We will not get rich by catering for them if that
takes time from doing useful things on mainstream machines.

> - fancy containers vs flat arrays for generic storage (e.g coordinates, forces).
> - cache-friendly and concurrent data-structures (required in core
> probably not in tools).
> - AoS vs SoA.
>
> I know these suggestions are rather vague, so I think here's the point
> where a  bit of brainstorming could help.

This kind of modularity would be very nice. But if we do not use
virtual functions, templates or macros, how can we write an interface
for a container for generic storage of coordinates that can have
different implementations depending on the module? What's your poison?
:-)

Mark

>> was discussed, I think I wrote a long e-mail (or perhaps a comment in
>> Redmine, can't remember) to enumerate some points that need to be
>> considered, with the result that the discussion died immediately... I can
>> try to look that up if people are really interested.
>
> Please do. I have probably not commented much (if at all) - sorry about that.
>
>>
>> Best regards,
>> Teemu
>>
>> --
>> 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.
> --
> 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.