compute the hetero flag a little bit different. The hetero flag is now
attached to a convertor if and only if we can use the optimized conversion
functions. It's a little bit broader than before (the 2 architectures
has to be identical).
This commit was SVN r11962.
conversion function are more complex and costly than a simple memcpy. Therefore,
we want to decrease as much as possible the usage of these functions.
We now check not only th HOMOGENEOUS flag on the datatype or convertor, but the
bits indicating a type is in use. If a communication transfert a type having the
same representation on both peers we can use the optimized version of the conversion.
In same time we build a more accurate conversion table for each master convertor,
based on the minimum differences between the 2 architectures.
This commit was SVN r11945.
different macros, one for each project. Therefore, now we have OPAL_DECLSPEC,
ORTE_DECLSPEC and OMPI_DECLSPEC. Please use them based on the sub-project.
This commit was SVN r11270.
final datatype not on the shape of the added datatype. The gaps exist if the
extent of the final datatype is not equal to its size.
This commit was SVN r10867.
correctly compute the final checksum. This is not a bug in the case where
both the sender and the receiver execute EXACTLY the same checksum
computations but is definitively a problem if not (such as the buffered case).
This commit was SVN r10367.
- add more comments on the pack and unpack functions.
- remove all pack/unpack versions that are not used anymore.
- other various cleanups.
- update the safeguard macro (which compute theboundaries of the
datatype in order to protect us from accessing memory locations
outside of the data).
- for the contiguous (with or without gaps) pack and unpack correctly
compute the starting point.
This commit was SVN r10327.
lower_bound is now directly added to the user pointer when the convertor
is created, instead of having to add it all over the places inside the
pack/unpack functions.
This commit was SVN r10292.
the cases. Instead replace it with a better solution, which work even for
fragments received not in order. However, this solution work only on the
current supported modes in ompi (homogeneous & heterogeneous with endianess).
The method is tricky. We will rely on 2 partial unpacks. First we will find
a byte that is not on the data to unpack, and we will pad the data with this
byte. Once we have the full length as expected, we will unpack the data, and
all the bytes in the unpacked form which do not match the unused byte will be
copied into the user buffer. This way we will reconstruct the unpacked data
in 2 times, once for the begining and once for the end.
This commit was SVN r10270.
they will be contiguous even when a multiple of them are send. This is the difference
between the NO_GAPS and CONTIGUOUS flags: contiguous one suppose that the data might
have gaps in the begining and/or at the end but the content of the data is contiguous.
This commit was SVN r10266.
pack is if the data has the BASIC flag which means it is predefined and contiguous.
For the unpack the convertor has to be homogeneous plus the same requirements
as for the pack.
This commit was SVN r10263.
