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
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:
It would be nice, if you could ammend this over time... What do you think?
Obviously I didn't do point 5 ,-(
> (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