Re: MPI implementations in squeeze
Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
> So the plan would be to use OpenMPI on all architectures where it is
> supported, and MPICH2 on the other ones, using mpi-default?
Yes.
> What do we do with LAM and mpich1? Target their removal for squeeze?
No, I would like to keep them for another release cycle so our users
have time to migrate. Removing all build-depends to them would be the
goal for squeeze, and a note in the release notes might be reasonable.
The removal could easily be done after squeeze.
On the other hand, they are not in the best shape, so this might be a
reason for them to go earlier. But it has been like that for quite a
while now, and a smooth transition might serve our users better. But I
really can't say what our users will prefer. Any input is very welcome!
> While I would be fine with that, there are other possible plans:
> (2) use MPICH2 as default everywhere (it is supported on all release
> archs). Clearly, the package didn't receive a lot of testing yet,
> but this is likely to be only a temporary problem.
I do not care that much. We chose Open MPI because it was the most
mature implementation at that time. I do not know much about MPICH2, and
am open to use MPICH2 as the default. I'd like to go with Open MPI, but
as one of the Open MPI maintainers in Debian, my view is biased. There
are some things that came into my mind:
* We shipped with Open MPI in the last release. This is no strong
argument, as the situation is still messy and we only had one
reasonable choice. I'm for switching if there is a good
technical argument about one over the other. If there isn't, I'd
prefer to stay with it as is.
* Open MPI does not build everywhere but it's well tested on the
platforms where it builds, and shown to work as expected. From
my experience LAM did build everywhere but did not run
everywhere. I do not know about the situation with MPICH2. If
it's functional on all platforms, it might be a good
alternative.
* The next upload of Open MPI will (probably) build on hppa. I
have worked with upstream and other contributors to add support
for other platforms, and we're working on more. For those not
supported, we plan to build using libatomic-ops. I'm not sure
when this will be done but I'm putting quite some efforts into
that so we will have that for squeeze. Also no strong argument,
I know.
* Upstream is very active and supportive. Response time is low and
all patches where included so far. They even coordinated a
release with us. It helped us a lot. Again, might be the same
with MPICH2, I just don't know.
Neither of those are strong arguments. I did not really want to argue,
anyway. The point was to get you all informed about what is going on on
the Open MPI side, as this is not really transparent most of the time.
If the situation with MPICH2 is similar to that of Open MPI, I'll not
object to use MPICH2 as the default. We should support our users by
enabling them to run parallel applications out of the box, with the
tools that work best (for them).
> (3) encourage people to provide packages for both MPICH2 and OpenMPI
> (where possible, or only MPICH2 if OpenMPI not possible).
There currently is no easy way to do that easily, the burdon is on the
maintainers side. We can (and should!) encourage them, but we have to
accept that not everyone wants that. I'd personally would build only
against mpi-defaults-dev, for the reason that the user gets a working
application by installing the -mpi package, without the need to know
which of the (conflicting) MPI packages to choose[*]. On the other hand,
it would be a shame if users prefering MPICH2 would have to build all
packages by hand. But I do not see an easy technical solution to that so
we can ease the building of multiple MPI packages (semi-)automatically.
I'm happy for all ideas on that, though.
Best regards, and sorry for the long mail!
Manuel
[*] I'm aware of the fact that MPI users usually know about things like
that but since multi-core machines get more and more frequent, we need
to support the less clueful users at some point.
Reply to: