[gmx-developers] libgromacs vs libgromacs_core?

[Jeff Hammond]

On Sat, Sep 28, 2013 at 11:49 PM, Teemu Murtola <teemu.murtola at iki.fi> wrote:
> 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.

I see no benefit of C++ here.  Performance compels the intelligent
mapping of virtual memory to hardware, which is best done in C.  How
does new[] deal with alignment issues and NUMA?

Jeff

>> - 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:
>
> 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.
> 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
>
> having duplicate, independent implementation for the same thing on both
> sides, or
> 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
>
> --
> 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.



-- 
Jeff Hammond
jeff.science at gmail.com