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 : https://svn.open-mpi.org/svn/ompi/tmp/ompi-ddt
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.
