I see the problem you pointed out, on binding the MPI types
to the specific (pointer) sizes in a heterogeneous environment.
However, I would MPI_Aint would be in trouble in heterogeneous
environments as well?
I mean, can we safely pass MPI_AINT back
and forth across 32-bit and 64-bit machines?
[I would guess not, one side would be chopped off anyway, right?]
No, no, I am not assuming that portability is any easy.
We try to make things portable as possible, a 'best effort' thing,
within reasonable limits.
I am glad all machines I am using now are 64-bit. :)
On 03/14/2013 02:52 PM, George Bosilca wrote:
> The short answer is yes.
However, this answer is wrong in a heterogeneous environment.
Suppose one rank is a 32 bits process, and the size_t is 4 bytes,
while another one is 64 bits with a size_t of 8 bytes.
If you correlate the sizeof(size_t) with the type you
use for a communication, then one process will use
MPI_UINT32_T while the other MPI_UINT64_t.
Based on the typemap matching rules defined by MPI,
there will be no automatic (MPI-based) conversion
between these two types.
> I'm just pointing out that the portability in MPI
is sometimes not as straightforward as one might assume.
> On Mar 14, 2013, at 15:09 , Gus Correa<gus_at_[hidden]> wrote:
>> Many thanks, George!
>> I passed MPI_AINT to the MPI functions,
>> along with the ptrdiff_t buffers,
>> and it worked right, at least for the modest
>> buffer sizes I tried.
>> I haven't got to size_t buffers yet, but if I understood right,
>> your suggestion for size_t buffers would be to
>> use MPI_UINT64_T as MPI data type on 64-bit machines, right?
>> [Probably MPI_UINT32_T on 32-bit, I presume.]
>> Thank you,
>> Gus Correa
>> On 03/13/2013 07:42 PM, George Bosilca wrote:
>>> MPI_Aint is always signed, as it is supposed to be able to
>> hold any relative difference between two memory locations.
>> This it is a good match for ptrdiff_t.
>>> There is no direct match for size_t, at least not
>> directly exposed by the MPI standard
>> (using the MPI-2.2 POSIX types, e.g MPI_UINT64_T).
>> My understanding is that size_t is unsigned,
>> and ssize_t is the signed synonym.
>>> On Mar 13, 2013, at 23:30 , Gus Correa<gus_at_[hidden]> wrote:
>>>> Dear Open MPI Pros
>>>> Which MPI data type corresponds to ptrdiff_t in C?
>>>> I guess the same question can be asked about size_t.
>>>> The FFTW3.3 MPI API has lots of stuff declared as
>>>> ptrdiff_t, and I need to pass them around with MPI,
>>>> hopefully without size or sign mistakes.
>>>> I am using Open MPI 1.6.3, if this matters.
>>>> My C goes as far as ABC, and in my naive view
>>>> ptrdiff_t is signed and has 64-bits on my x86_64 Linux computer,
>>>> whereas size_t is unsigned also 64-bits, right?
>>>> If I grep mpi.h for ptrdiff I see that OPAL_PTRDIFF_TYPE is
>>>> MPI_Aint, which is indeed an MPI pointer/address type.
>>>> However, this is OPAL, not generic MPI.
>>>> Moreover, MPI_Aint seems to be unsigned, right?
>>>> [And this would make it a bad match for ptrdiff_t,
>>>> but maybe a good match for size_t.]
>>>> Or is MPI_Aint signed?
>>>> [grep result:]
>>>> 147:/* type to use for ptrdiff_t, if it does not exist, set to ptrdiff_t if it does exist */
>>>> 148:#define OPAL_PTRDIFF_TYPE ptrdiff_t
>>>> 218:/* include for ptrdiff_t */
>>>> 317:typedef OPAL_PTRDIFF_TYPE MPI_Aint;
>>>> OTOH, there are bunches of signed and unsigned integer MPI types
>>>> in mpi.h.
>>>> In a 64-bit machine, besides MPI_Aint,
>>>> I guess possible candidates would be
>>>> MPI_INT64_T and MPI_UINT64_T.
>>>> But which one: signed or unsigned?
>>>> Even if I write a little function to find an MPI integer type
>>>> with the same extent as sizeof(ptrdiff_t), it may still
>>>> return more than one type, and be problematic to pick one
>>>> (e.g., signed or unsigned?).
>>>> Any help is appreciated.
>>>> Gus Correa
>>>> users mailing list
>>> users mailing list
>> users mailing list
> users mailing list