Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: [OMPI devel] [RFC] Move the datatype engine in the OPAL layer
From: George Bosilca (bosilca_at_[hidden])
Date: 2009-07-07 17:57:22

What : Split the datatype engine in two parts: one MPI agnostic in the
OPAL layer and one holding the MPI knowledge in the OMPI layer.

Why : There are several reasons. One is cleanness of the code, the
lower layer only deals with POSIX types ([u]int[1,2,4,8]_t,
float[4,6,12]_t, wchar and bool). All the conversions works on only
these types, everything else is built on top of these types. Second
reason, is that now the data-type engine (without all the MPI
knowledge) is available to other projects.

Where :

When: Over the weekend of July 11th.

Long[er] Version

Logically split the datatype engine based on the MPI knowledge
requirements. The lowest layer is dealing with only the POSIX
compliant types (aka fewer types), while the upper layer is mainly
dealing with the matching of the MPI types with the POSIX ones (based
on their size and alignment), storing language semantics a type was
created from, keeping track of all the MPI features (such as
get_content) and implementing optimized version of the composed
datatype creation (contiguous, vector and co.).

Additionally, this will allow easy implementation of MPI_INT8_T and
friends of the upcoming MPI-2.2 ;-)

While the code has been moved around quite a bit and most of the files
have been [nicely] renamed, we keep the usual Open MPI development
model, with objects derived from other objects. As a result the
ompi_datatype_t is derived from the opal_datatype_t, plus some fields
to deal with the MPI requirements.

Correctness tests are done using mpi_test_suite and intel tests.
Further MTT test would be nice!

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).

   george & rainer.