[gmx-developers] libgromacs vs libgromacs_core?

[Szilárd Páll]

On Sat, Sep 28, 2013 at 8:00 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
> On Sat, Sep 28, 2013 at 7:17 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
>> On Sat, Sep 28, 2013 at 6:55 PM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
>>> On Sat, Sep 28, 2013 at 5:56 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
>>>> Hi,
>>>>
>>>> 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.
>>>
>>> What external dependencies do we have that are optional for mdrun and
>>> cannot be turned off at CMake level?
>>
>> I'm not familiar with the current dependencies of 5.0 code to a great
>> detail, but actually I have mis-phrased the problem statement.
>
> This has been discussed at great length over years on this list and on
> Redmine. The summary material on the web is a pretty accurate state of
> affairs: we require C++98; stuff in POSIX is probably fine, but be
> aware there are non-POSIX platforms. For example, we want smarter
> pointers than C++98, and so we bundle a few pieces of Boost that make
> that possible, unless the compiler in use offers C++11 support.
>
>> It is not just a matter of what _libraies_ does mdrun depend on _now_,
>> but in general, what will go into libgromacs that could potentially
>> set back porting mdrun to a new platform in (almost) as little time as
>> in the days of C99 code <v5.0 code. This includes external library
>> dependencies as well as language features and constructs which may
>> prevent porting or efficient use on some hardware.
>
> This, too, has been discussed a lot. There's a list of allowed C++
> constructs on the website.

Sure, I know. However, AFAIK, this list has even grown throughout the
years, and I don't know whether anyone has actually checked whether
all accepted features are implemented and work well even in
non-mainstream compilers.

>> Additionally, one can also look at the issue the other way around:
>> while maintaining the portability of mdrun should be a major goal,
>> having to keep this restriction in mind when writing tools code is
>> both a burden as well as a risk - it takes a C++/HPC expert to know
>> what language features of say C++11 are "too much" for non-mainstream
>> compilers (and we have a trend of squeezing in more and more allowed
>> stuff). Hence, IMO it would be advantageous to not have to scrutinize
>> every bit of code for a high level of portability that goes into
>> libgromacs because, I think, that's the sure way to make the situation
>> disadvantageous for both mdrun and tools.
>
> Right, so we are being very conservative. If we are ever able to
> separate modules such that we can relax that requirement (e.g. for

Why the "if"? The least one could do is to allow building a light
libgromacs that does not act as a kitchen sink into which tons of code
gets compiled in just because tool X needs it.

Correct me if I'm wrong, but to me it seems that this is more of a
matter of prioritizing such a "feature" (=portability). Of course, it
may take a bit of effort to design all the C++ stuff such that core
mdrun features are easily separable, but it's better to do it now than
when the lack of such design considerations may start to hurt.

> ease of writing tools code) then we can consider doing that. But for a
> non-trivial period of time, the question of whether a compiler can do
> what parts of C++11 efficiently or portably is moot. The first
> fully-compliant C++11 compilers are fresh on the market, and GROMACS
> is pretty unmodular.

C++11 was just an example. AFAIR even including boost code was out of
the question when the C++ discussion first started, but it still got
embraced.

>
>> While it may seem that I'm putting too much emphasis on this, I know
>> concrete examples of projects which took a disproportionate amount of
>> time to get running on some platform simply because of dependencies or
>> the use of C++ and its features.
>
> Sure. We are trying to learn from those lessons. What do you think we
> need to do more?

Unfortunately, I don't have strong enough experience with C++ in HPC
and probably many of us don't. Hence, I can't write up the list 10
commandments to follow - especially that there is no such list, at
least not a universal one. Just as an example, an acquaintance of mine
who has worked in HPC with both C and C++ for a decade or so said that
he'd never use most C++ features in performance-oriented code like
virtual functions, most of what templates offer, exceptions, just to
name a few I can remember.

Of course, there is room to analyse every feature on a case-by-case
and per-project basis, but I personally have a hard time providing
much concrete and useful input due to my lack of extensive experience.

Cheers,
--
Szilárd

> Mark
> --
> 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.