[gmx-developers] Making libgromacs a dynamic loadable object

[Mark Abraham]

On Sep 29, 2013 10:32 AM, "Erik Lindahl" <erik.lindahl at scilifelab.se> wrote:
>
> Hi,
>
> 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().

I can see three possible division levels: mdrun vs tools, md-loop vs rest,
hardware-tuned inner loops vs rest. The third is by far the easiest to do.

Cray still requires static linking, and BlueGene/Q encourages it, so I
think it is important that the implementation does not require dynamic
linking in the cases where portability of the binary is immaterial.

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

I think the third option I give above is the most achievable. I do not know
whether the dynamic function calls incur overhead per call, or whether that
can be mitigated by the helper object Teemu suggested, but he sounds right
(as usual). I hope the libraries would share the same address space. Since
we anyway plan for tasks to wrap function calls, the implementations
converge.

> Mark: Considering (2), we might for instance prefer to move the main md
loop to a library function.

That's an option, but so far I do not see the benefit of it over the third
option. I expect there is no strong reason for compiler-driven
hardware-aware optimization at some level. An hour or two with cmake would
test this point, as I suggested on the multi-architecture redmine from
February, but nobody has taken it up.

> Obviously, we could also use an extra library or two for
architecture-specific code in programs/tools/testutils, but that might be
uglier?

Not sure what you mean.

Mark

> Cheers,
>
> Erik--
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130930/f228e76b/attachment.html>