Re: [pooma-dev] Merging native MPI parallelization

[Richard Guenther]

On Thu, 18 Dec 2003, Jeffrey D. Oldham wrote:

> Richard Guenther wrote:
> > Hi!
> >
> > I'd like to merge in a native MPI parallelization.  Unfortunately the
> > patch is huge and touches a lot of files.  Basically one part of the patch
> > introduces a new #define POOMA_MESSAGING and replaces occourences of
> > POOMA_CHEETAH with POOMA_MESSAGING where appropriate.  A lot of tests are
> > touched by this and also all the remote engine stuff.  Second, the common
> > entry header for messaging support is changed to Tulip/Messaging.h which
> > can be unconditionally (or conditionally on POOMA_MESSAGING) included
> > instead of Cheetah/Cheetah.h.
> >
> > After merging the above changes, the remaining part should only touch
> > Tulip/ and the remote engines.  Unfortunately, the serial async scheduler
> > is also hacked to support async completion of MPI requests.
> >
> > Would it be ok to merge the first part unconditionally in if the second
> > part will be accepted?  If it is, I'll try to split the patch
> > appropriately.
>
> Native MPI support will be good because it will lower the barrier to
> parallel use.

Yes, that was my primary goal.  Also enhancing performance turned out to
be a _lot_ easier with a native MPI interface than with Cheetah.

> At the same time, there are probably still Cheetah users
> and we should support them.  Can we do so using POOMA_CHEETAH and
> POOMA_MESSAGING preprocessor definitions?

Yes, at the moment I have POOMA_MESSAGING for general support,
POOMA_CHEETAH for Cheetah specific parts and POOMA_MPI for MPI specific
parts.  So, for both POOMA_CHEETAH and POOMA_MPI, POOMA_MESSAGING is
defined, but POOMA_CHEETAH and POOMA_MPI are mutually exclusive.

> Packaging the changes to have reasonable size can be difficult.  I think
> all changes should be presented as patches for community review.
> ChangeLog entries will help understand the changes.

I'll try to start with the patch to introduce POOMA_MESSAGING.  That
should be touching a lot of files, but in a very obvious way.

Thanks,

Richard.