Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [RFC] Move the datatype engine in the OPAL layer
From: Rainer Keller (keller_at_[hidden])
Date: 2009-07-14 13:23:27


Hi Jeff,
On Tuesday 14 July 2009 11:39:59 am Jeff Squyres wrote:
> 1. My questions were not answered before the DDT split was merged to
> the trunk.
OK, sorry about that.
Well, actually the answer to both questions are yes.

> 2. The number of "fixup" commits and things that broke on the trunk
> after the DDT split was merged seem to indicate a lack of testing.
> What happened?

Yeah, basically I didn't run through
1. make distcheck, which when copying the sources to a sub-directory and
compiling from there was
a.) missing the header file in ompi/datatype/ompi_datatype_internal.h in
Makefile.am
b.) make distcheck later correctly checked opal_datatype_test, however needed
to know about opal_ddt_lib.c

2.) didn't check with checkpoint restart (I'd need to setup blcr on this
computer again) -- the code was accessing the ddt-structures directly.

3.) Windows compiler needed DECLSPECs.

As it turned out, several other header-file and configure changes unrelated to
DDT needed to be brought over, which Shiqing did.

So, in order to also help others before merging quite intrusive changes, I
have started a howto in our wiki:

https://svn.open-mpi.org/trac/ompi/wiki/HowtoTesting

It would be nice, if you could ammend this over time... What do you think?

Obviously I didn't do point 5 ,-(

CU,
Rainer

> (perhaps this was addressed on the teleconf today; I was not there --
> if it was discussed, forgive the redundancy...)
>
> On Jul 9, 2009, at 7:08 AM, Jeff Squyres wrote:
> > Two comments:
> >> Why : ... Second
> >> reason, is that now the data-type engine (without all the MPI
> >> knowledge) is available to other projects.
> >
> > We're still only shipping Open MPI as a whole as our official
> > product, right? More specifically: we're not intending to ship OPAL
> > independently, right? If other projects want to pick up OPAL
> > themselves and use it (e.g., via SVN checkouts, Mercurial clones,
> > official OMPI tarballs, etc.), that's fine. But I'd be opposed to
> > creating a 2nd official distribution that was OPAL-only.
> >
> >> Performance tests on the ompi-ddt branch have proven that there is no
> >> performance penalties associated with this change (tests done using
> >> NetPipe-3.7.1 on smoky using BTL/sm, giving 1.6usecs on this
> >> platform).
> >
> > 1.6us sounds like pretty high sm latency... Is this a slow platform?
> >
> > --
> > Jeff Squyres
> > Cisco Systems

-- 
------------------------------------------------------------------------
Rainer Keller, PhD                  Tel: +1 (865) 241-6293
Oak Ridge National Lab          Fax: +1 (865) 241-4811
PO Box 2008 MS 6164           Email: keller_at_[hidden]
Oak Ridge, TN 37831-2008    AIM/Skype: rusraink