Eray Ozkural (exa) wrote:
>LAM seems to be more practical, and since it doesn't bring performance
>penalties it's our implementation of choice.
>
That's about what I thought.
>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.
>
>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.
>
That makes sense. I'll leave it with mpich at least until lam 6.5.2 is
in unstable.
Regarding standards, since it is built to work with both, I imagine
PETSc either doesn't use mpich-specific interfaces, or else has
workarounds for interface differences, so "whichever is faster" is the
correct choice. But this means I probably should do more extensive
testing than just a few nonlinear finite difference problems, maybe a
couple of dense matrix tests too, which could give mpich an advantage if
PETSc does use MPI_AlltoallW().
Also, since we're largely an x86 community, and Linux has only recently
started to scale to larger SMP machines, I imagine most Debian PETSc
users are of the Beowulf variety, with relatively inexpensive
networking, i.e. not myrinet. But I could be wrong... In any case,
"whichever is faster" should be the fastest implementation for the most
people, and let the rest just do (assuming lam is chosen):
apt-get source petsc
cd petsc-2.1.0
debian/rules PETSC_MPI=mpich binary
Thank you for bringing these issues to my attention, I'm pretty much
"just a user" with barely enough knowledge of internals to make stuff
work. :-)
>Hmm, I think I should look at the neat petscgraphics ;)
>
Now that it's uploaded for more than just powerpc, you should be able to
just apt-get install petscgraphics1-demo to drag in its dependencies,
and then run chts or "mpirun -np X /usr/bin/chts". I'm working out a
divide by zero issue, then will upload for alpha too.
At this point, the slow steps are sending the triangles to geomview, and
rendering them there; the triangulation generation itself is fast even
on one CPU. And it exposes the geomview transparency bug, so for all
those reasons I need to get away from the current architecture. I'm
thinking of using Evas to render the semi-transparent triangles into a
pixmap on each processor, then just have node 0 layer those
semi-transparent pixmaps. Or is there a good, fast alternative to Evas? :-)
Zeen,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
