[gmx-developers] 4.6 Binaries and Acceleration levels

[Berk Hess]

On 07/06/2012 05:51 AM, Nicholas Breen wrote:
> On Thu, Jul 05, 2012 at 11:05:53PM +0200, Szilárd Páll wrote:
>> On Thu, Jul 5, 2012 at 10:59 PM, Christoph Junghans<junghans at votca.org>  wrote:
>>> Roland has a good point, but Debian and Fedora already compile Gromacs
>>> for different mpi version.
>>>
>>> 4 acc. x 3 (serial,openmpi&  mpich2) = 12 packages!
>>>
>>> @ Jussi: Would that still be possible?
>> I guess possible is one thing and probable is a totally different one...
>>
>> Perhaps it would be good to ask the Ubuntu/Debian maintainer as well...
> I would not want to create that much package complexity (the gromacs source
> package already builds five binary packages!), especially if it would all be on
> only one of the many architectures supported, and I cannot think of any other
> package in the Debian archive that operates that way -- everything that I know
> of with multiple CPU optimizations uses run-time detection, except for the
> unavoidable cases with packaging the Linux kernel itself.  If it is
> functionality that is contained purely within the shared libraries, then
> glibc's hwcap support might be a workaround if the build system can permit
> compiling one copy of the libraries for every supported variant.  Otherwise, if
> it's all within mdrun itself, maybe just stick to run-time detection and
> downgrade or eliminate the warnings it issues for "suboptimal" CPUs?
>
>
Erik's non-bonded kernels are present as source in all flavors.
My non-bonded kernel sources can easily be put in in all flavors.
Then we would still need compilation and call selection support.
But there is also x86 SIMD code in the PME and bonded code,
as well as in some other parts of the code. Unless we have a
high level way of dealing with this, things with get messy.
Also the compiler can add e.g. AVX instructions in plain C code.
So if it can be handled by compiling different shared libraries,
that would be far simpler. All compute intensive functionality
is in the shared libraries, so that's no issue.

Cheers,

Berk