Am Montag, den 16.03.2009, 13:43 +0100 schrieb Francesco P. Lovergine: > A disclaimer: I'm no more a MPI user currently, so take my opinions with > a grain of salt. No worries. My point of view is biased by my Open MPI maintainership. Any input is welcome if we want to resolve the MPI issues in Debian, so please do not hesitate to express your opinion! :) > On Sat, Mar 14, 2009 at 04:56:41PM +0100, Manuel Prinz wrote: > > 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. Right. I also have a not-too-good feeling about LAM as fallback but it is currently the best option we have, I suppose. First, most developers of LAM or now working on Open MPI. So both have similar roots and upstream is very helpful and responsive. It's actually quite a pleasure to work with them. Second, there are itches with MPICH that I personally consider them to be unfit as a substitute, e. g. that MPICH does not work with SLURM (bug #446883), a resource manager that gets more and more popular. (I really like it myself, so again, bias here.) So, if we go for MPICH on arches not supported by Open MPI currently, we also lose integration into resource managers, which makes it not a good choice. I totally agree with you that LAM is a bad solution from a technical point of view, but the second best choise from a distribution point of view, as of now. > > 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. Yes, this is something I thought about as well. I'm working quite hard on getting Open MPI to build on all architectures. Progress is quite slow but I hope to finish before Squeeze. The aim is to replace LAM with Open MPI, if possible. As for MPICH2, I have intention to package it. I'd be happy if anyone would do it, so we can replace MPICH in the long run. Also, we should decide (as a project) how to deal with MPI implementations in general, meaning if we "support" only one, meaning that packages build against one we chose, and the others are installed as libraries, or if we build packages against all available ones. I'm really unsure about this still. > 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. Sure, that needs to be done. What do you mean by "holding on any re-implementation"? Best regards Manuel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil