[gmx-developers] Making libgromacs a dynamic loadable object

[Teemu Murtola]

Hi,

On Sun, Sep 29, 2013 at 11:32 AM, Erik Lindahl
<erik.lindahl at scilifelab.se>wrote:

> I think this is unlikely to make it for 5.0, but long-term I would like to
> support multiple hardware accelerations in a single binary again, by making
> the actual binaries very small and loading one of several libraries as a
> dynamic module at runtime. This is not technically difficult to do, but
> there is one step that will be a little pain for us: Each symbol we want to
> use from the library must be resolved manually with a call to dlsym().
>
> This means we should start thinking of two things to make life simpler in
> the future:
>
> 1) Decide on what level we want the interface between library and
> executables, and keep this interface _really_ small (in the sense that we
> want to resolve as few symbols as possible).
> 2) Since we will have to compile the high-level binaries with generic
> compiler flags, any code that is performance-sensitive should go in the
> architecture-specific optimized library.
>
> Mark: Considering (2), we might for instance prefer to move the main md
> loop to a library function.
> Obviously, we could also use an extra library or two for
> architecture-specific code in programs/tools/testutils, but that might be
> uglier?
>

Of this, I'm sure that I've written some technical comments that never
provoked any response. ;) It's in Redmine issue 1165, comment
#19<http://redmine.gromacs.org/issues/1165#note-19>
.

I agree that using dlsym() is tedious. However, with proper organization of
the code it should be sufficient to resolve a single C factory function
using dlsym(), and return a C++ object that is used to make all other
calls. Of course, if using virtual functions and other "fancy" C++ stuff is
out of the question for whatever reasons, we can also implement a similar
mechanism in plain C by returning a struct of function pointers. But that
is _exactly_ the same thing that the C++ compiler can do for us, in a much
more convenient manner, so I don't really see a point in doing that.

The interface needs to still be though out to keep it reasonable
(essentially, every call across the boundary is a call through a function
pointer, whether in C++ or C, so it can't be done in an inner loop), and
this is where the real effort lays.

Also, we can't move everything into the binary or architecture-specific
optimized libraries if we still want to make it possible for people to
write tools that link against Gromacs. All code that such user tools need
needs to be in an easily usable library; this includes a lot of the basic
command-line processing machinery etc.

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