Re: PETSc Debian package switch to lam?
Adam C Powell IV wrote:
>
> Greetings,
>
> [petsc-users, this only affects you if you run Debian GNU/Linux.]
>
> With my big cluster not quite up yet, I can't quite do the big mpich vs.
> lam benchmark I had hoped to, and have to trust the judgment of others.
> There seems to be a rough consensus that lam is better (from people
> like Eray Ozkural on debian-beowulf), so with freezes approaching, I'd
> like to switch the Debian package to use lam.
>
It's hard to do justice here, with mpich being the pioneering implementation.
LAM seems to be more practical, and since it doesn't bring performance
penalties it's our implementation of choice. Nevertheless, I would not suggest
switching to lam unless we have the 6.5.2 stable version available in
debian which we do not. The 6.5.2 will require packaging changes,
the debian diffs for 6.3.2 won't work. I will present new versions for
testing soon hopefully. Anyway, the new lam version builds and installs
with ./configure, make and make install so it's quite trivial.
> I don't know how many Debian PETSc users there are, but what this would
> mean is that either you'd have to recompile your PETSc-based apps
> against the new -dev packages, or build mpich-based PETSc libs, or just
> not upgrade from 2.1.0-1. (I think petscgraphics is the only Debian
> package depending on it.) Since the package is still in
> unstable/testing, I do this with little remorse, but if there is valid
> technical justification (within a week or so), I'll stick with mpich.
>
The technical justification for mpich would be
1. a more complete / up-to-date implementation
2. better performance
Generally, I haven't observed (2). However, for custom hardware mpich
may be better (i.e. myrinet) And note that it has been used and extended
by many vendors as a reference implementation. (1) Standards compliance
is surely a more important matter. For instance, there is the new
MPI_AlltoallW(... many args ...)
function intended for matrix computations. If the new mpich has it while lam
lacking, then for the sake of standard mpich would be better.
> As for "why not binaries for both?", PETSc is huge, weighing in at 56 MB
> in pool/main/p/petsc (65% of which is the -dbg packages), and for the
> mirrors' sake, I'd rather not double that.
Certainly, the size is too large for compiling against both implementations.
Hmm, I think I should look at the neat petscgraphics ;)
Thanks,
--
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>,
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
Reply to: