Re: MPICH as default MPI; WAS: MPI debugging workflows
On 2018-12-08 12:31, Drew Parsons wrote:
On 2018-12-07 19:49, Alastair McKinstry wrote:
Looking into it further, I'm reluctant now to move to mpich for buster
as the default. One was the experience of the openmpi3 transition,
shaking out many issues.
I suspect we could see the same with other package builds, as you
point out, tuned to openmpi rather than mpich, but also the feature
support for mpich.
...
So I think more testing of mpich3 builds with CH4 /pmix / OFI support
is needed, but moving over openmpi-> mpich at this stage is iffy.
Thanks Alistair, your analysis sounds sound. I'm happy to be patient
with the switch and wait till after buster, especially if pmix support
complicates the matter. That will make it all the more useful to set
up a test buildd to test the transition.
I'll invite upstream authors who have been promoting mpich over
openmpi to chip in with their experience.
I received this feedback from a PETSc developer:
"The Open MPI API is better for developers due to better type safety
(all
handles in MPICH are typedef'd to int). Most major commercial vendors
are organized around variants of MPICH (where there is collective ABI
standardization). Open MPI is more modular so most vendor stuff goes
into their plugins (for those vendors working with OMPI).
"I think a good solution for Linux distros (and many others) would be
to
make a library that is ABI compatible with OMPI, but dispatches
through
to MPICH. There exists a (messy) open source demonstration.
" https://github.com/cea-hpc/wi4mpi/ "
ABI compatibility sounds like a nice resolution of the dilemma.
Drew
Reply to: