Greetings, On Sun, 2011-04-10 at 17:13 +1000, Drew Parsons wrote: > On Sat, 2011-04-09 at 14:12 +0200, Manuel Prinz wrote: > > On Fri, Apr 08, 2011 at 10:54:47AM +1000, Drew Parsons wrote: > > > I'm happy to leave bug #575259 untouched if you suspect the patch might > > > be unreliable. I just want lam gone so packages can autobuild. I have > > > no substantial preference between openmpi and mpich2, unless mpich2 > > > should give the same build problems that lam did. > > > > I do not think it is reliable and needs further testing. I'll give a short > > summary of what is going on in this direction and we should discuss how to > > proceed: > > > > - I'm currently packaging Open MPI 1.5 and am working with upstream to > > add support for currently unsupported architectures. It's looking quite > > good so openmpi will build on at least armel and mips(el), maybe others > > or even all architectures. > > - I'd prefer to fix mpi-defautls once we have both openmpi and mpich2 build > > on all architectures, so that we can go for one. (I'm not really in favor > > for one or the other.) I disagree with waiting. We've been waiting for better openmpi arch support for a very, very long time. I tried to work on it a couple of years ago using libatomic-ops, to no avail. LAM is causing packages to FTBFS *now* (PETSc with HDF5 support and gmsh to name two). FWIW, my "vote" would be to go ahead and replace LAM with MPICH2 on the non-OpenMPI arches now, and remove LAM and MPICH1 from the archive. Or if we decide MPICH2 is better than OpenMPI, default to that everywhere. Either way, let's get rid of LAM and MPICH1, and switch mpi-defaults, sooner rather than later. > Judging by the build logs at > https://buildd.debian.org/pkg.cgi?pkg=mpich2, mpich2 is already building > on all architectures. Will be nice to have openmpi available everywhere > too though (not that people will be setting up mpi jobs across their > armel smartphones, but it's the principle of the matter... :) ). Actually, giving large computers and data centers the flexibility to switch between x86[_64]-compatible and ARM or MIPS cores is a real issue in terms of power usage -- one where Debian's mostly-seamless multi-architecture support is a major benefit. > - Using update-alternatives in the MPI packages to replace a library did > > always bother me and I think this is broken. We should consider modifying > > the packages in a way so that mpi-defaults would provide libmpi.so. I did > > not check how a migration path would look like, though. I somewhat agree. Update-alternatives often breaks down because one package provides a link which others don't, etc., leaving one with stranded links or missing links. On the other hand, it's a pain to have to remove and later reinstall, say, OpenMPI -- and all of its rdeps -- just to test building something with, say, MPICH2, so to the extent the alternatives system works it can be quite helpful. On Sun, 2011-04-10 at 14:32 +0200, Lucas Nussbaum wrote: > On 10/04/11 at 17:13 +1000, Drew Parsons wrote: > > A related side question: what are the current pros/cons of openmpi vs > > mpich2, aside from architecture support? > > The market share for openmpi is currently larger than the one of > mpich2, so defaulting to openmpi sounds like a better idea if it can > work on all architectures. This is a small detail relative to getting rid of LAM, but if you're talking about popcon, that's likely because OpenMPI is the default on the post popular arches (amd64, i386, powerpc, ia64, kfreebsd-*), so most people who install MPI-related software will get it. You have to do quite a bit more work to use MPICH2 on those arches. Or are you talking about the broader world beyond Debian (and Ubuntu)? If so, I'd love to hear more... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part