Re: MPI defaults
A disclaimer: I'm no more a MPI user currently, so take my opinions with
a grain of salt.
On Sat, Mar 14, 2009 at 04:56:41PM +0100, Manuel Prinz wrote:
> Am Samstag, den 14.03.2009, 10:54 +0100 schrieb Francesco P. Lovergine:
> > while working on HDF5 I'm considering to move MPI support to use mpi-default-dev
> > and mpi-default-bin. That would imply providing a single reference platform support
> > (openmpi or lam, completely dropping mpich AFAIK) which is quite different from what
> > done until today. I wonder if it would be appropriate having instead a mpi-all-dev and
> > mpi-any-bin package which depends on all supported platforms
> > on every archs. That would allow transparently building lam, mpich and openmpi
> > flavors whenever possible, and depending on any appropriate tool the admin would install.
>
> That is probably the goal to go for but there are some technical
> problems with it. Most debian/rules can't easily include a snippet and
> finally do the right thing.
>
> There are also some other issues: Most MPI implementations do not play
> well together, meaning there currently are problems if two or more are
> installed. (Yes, there shouldn't be, but it's an unresolved issue as of
> now.) Also, LAM/MPI can be considered to be dead upstream and is not
> recommended for usage, I think Debian should not build against it
> anymore;
...which is not mpi-default is doing now, because the choice
is OpenMPI vs LAM, indeed. I wonder if non-LAM can be a viable
choice for all archs anyway. I have not information about that.
But for that I think all admins use just one implementation for
their whole cluster, the problem is not having the missing one
to install :-) That was my motivation to discuss the use
of the 'preferred' one instead of any of the available ones.
> there's nothing against still providing the libraries, of
> course. Also, MPICH is superseeded by MPICH2 which noone ever packaged.
> I do not know the details but as I check last, MPICH2 seems to not have
> support for modern inter-conntects. They are supported via forks, so one
> would have to package a MPICH2 version for each interconnect.
>
Therefore, it seems to me appropriate having only OpenMpi and Mpich2
implementations for the future. Both them to be verified per each arch.
> Mpi-defaults was supposed to support package who need MPI support, and
> give it to them in an easy way. I was not designed to be a full-blown
> solution. it definitely worth for such a solution but several questions
> need to be addressed first. I do maintain a list of issues that in my
> opinion need to be resolved first. I need to write it up in a better way
> and have it discussed here and in pkg-scicomp first. Also, we should
> check if we really want so many (and out-dated) MPI versions in Debian,
> of if we can go with one for the apps and provide libs for all others.
> If MPI were to be standardized on ABI compatibility, that resolve the
> whole issue. But since this is not going to happen anytime soon, we have
> to work on a solution that works for us.
>
> I really welcome your idea and would be glad to hear suggestions if you
> have an idea of how to implement that! I also hope we can have the
> discussion about MPI in Debian soon; but I currently have to spend the
> time to fix "my" MPI implementation before I can write up a proposal.
>
> Best regards
> Manuel
On this basis, I think that it would be the case to hold on any re-implementation
of the MPI related packaging for HDF5. It is much better defining a decent
policy draft before proceeding with modifying packages here and there.
--
Francesco P. Lovergine
Reply to: