[gmx-developers] libgromacs vs libgromacs_core?

[Teemu Murtola]

Hi,

On Sat, Sep 28, 2013 at 9:58 PM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:

> 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:
>

Some comments inline on some.


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

While in principle possible, I think this requires someone to write a lot
of code; see the main point at the end of the e-mail. What could be more
doable is to make it _possible_ to compile this part without exceptions
(but not the default), but with some reduced functionality (like, program
immediately terminates on errors, and some context information for the
error message is lost).


> - fancy containers vs flat arrays for generic storage (e.g coordinates,
> forces).
>

std::vector is a flat array. ;) But if we want to have control over the
allocation strategy, we may need a custom container. But still, basic C++
containers make writing the code a lot easier.


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

Couldn't find that with a bit of searching, so perhaps faster to write it
again. I'm quite sure I've mentioned at least of some of this somewhere to
someone earlier, though. ;)

The first point is that there are really two concerns, and we should be
clear which one we are trying to address by which proposals:

   1. Are we concerned that the code will be difficult to compile at all?
   Here, it is very difficult to predict what some future compiler may or may
   not support. The standard has a concept of a limited free-standing
   implementation for embedded systems, but I think that it allows a very
   stripped-down standard library, not skipping support for any language
   features.
   2. Or are we concerned that C++ code will be difficult to get efficient?
   For the efficiency, it is overly zealous to prevent using even basic C++98
   features in code that has no impact on performance. Examples being code
   that parses command-line options or prints out 'mdrun -h' or such. About
   the only C++ feature for which you may pay a performance penalty even in
   code where you don't use it is exceptions: early compiler implementations
   incurred some overhead by just turning exception handling on. But it should
   be perfectly fine to compile the kernels and some other low-level code in C
   if that is a major concern. And/or add an option to build without
   exceptions as mentioned above.

That brings me to my main point: there is a lot of code that is shared by
mdrun and tools. Examples are command-line parsing and many kinds of file
I/O. If we want to be strict about the split, and the tools need features
in there that is not allowed by our stricter rules for mdrun, then we
somehow need to duplicate the code. This means either

   1. having duplicate, independent implementation for the same thing on
   both sides, or
   2. having a complex layered system with a core implementation for these
   features, and then wrapper (at least for the tools, but possibly also for
   mdrun) to add fancier features on top of that.

The current implementation may serve as a basis for 1., but not really for
2., since it is littered with gmx_fatal() calls, and the tool code really
wants to have proper error handling. I haven't seen much enthusiasm to put
a lot of effort into such work that this would require, which is why I
think this will be the main hurdle.

Finally, my mention of "limited features" for such reduced mdrun were more
directed towards all this shared support code rather than actual mdrun
features. For example, "do we need mdrun -h in the reduced mdrun?" (this
could be directly shared with tool code, but it's a lot easier to write it
with less strict rules), or "do we need exactly the same error messages,
with all nice-to-have context information, in the reduced mdrun?".

Best regards,
Teemu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130929/82b31eef/attachment.html>