<p dir="ltr"><br>
On Sep 29, 2013 10:32 AM, "Erik Lindahl" <<a href="mailto:erik.lindahl@scilifelab.se">erik.lindahl@scilifelab.se</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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().</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> This means we should start thinking of two things to make life simpler in the future:<br>
><br>
> 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).<br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Mark: Considering (2), we might for instance prefer to move the main md loop to a library function.</p>
<p dir="ltr">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. </p>
<p dir="ltr">> Obviously, we could also use an extra library or two for architecture-specific code in programs/tools/testutils, but that might be uglier?</p>
<p dir="ltr">Not sure what you mean.</p>
<p dir="ltr">Mark<br></p>
<p dir="ltr">> Cheers,<br>
><br>
> Erik--<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</p>