[Mpi-forum] why (int)0x4c000101 ?
ftillier at microsoft.com
Sun May 27 14:15:15 CDT 2012
To add to what Jeff said, think of MPI_Datatype as information about a buffer being passed in. Take for example MPI_Send, which takes as input a void* 'buf' parameter for the buffer to send. The datatype parameter to MPI_Send give the function information about the type pointed to by 'buf'.
To that end, you want your MPI library to be able to quickly decode an input datatype so that it may get on with processing the actual buffer. Different MPI libraries do this differently, as Jeff highlighted with the comparison of MPICH vs. Open MPI.
Jeff Hammond wrote on Sun, 27 May 2012 at 08:51:27
> The values appear to be designed to be decoded quickly using e.g.
> bitmasks. Comparing a general character string to "char" is expensive
> relative to a bitmask. Just write write a C code to that compares
> strncmp/strcmp to |/& and you'll see this clearly.
> One will observe that information appears to be coded in those values.
> You see that the third-to-last hex-digit indicates the number of bytes
> in the type, with the exception of long double, which uses c=12 when
> the type is actually 16 bytes. I don't know why this is, but it
> doesn't really matter since there is only one built-in type of this
> size. Inspecting the first- and second-to-list hex-digits indicates
> that signed and unsigned types often (but not always) differ by only
> one bit.
> I didn't write that code but it is clear that the author was concerned
> about performance, not human readability, although the scheme is clearly
> not random, so I suspect it is quite readable to the MPICH2 developers.
> You can look at OpenMPI for a different perspective on implementing
> these types:
> #define OMPI_PREDEFINED_GLOBAL(type, global) ((type) ((void *)
> &(global))) OMPI_DECLSPEC extern struct ompi_predefined_datatype_t
> ompi_mpi_char; #define MPI_CHAR OMPI_PREDEFINED_GLOBAL(MPI_Datatype,
> You'll have to look at the source if you want more information. I
> know very little about the internal design of OpenMPI.
> On Sun, May 27, 2012 at 9:42 AM, ÄþÄþ ¶ <dncdd at yahoo.com.cn> wrote:
>> when I read mpich2-1.4.1 code, I saw code as follow:
>> typedef int MPI_Datatype;
>> #define MPI_CHAR ((MPI_Datatype)0x4c000101)
>> #define MPI_SIGNED_CHAR ((MPI_Datatype)0x4c000118)
>> #define MPI_UNSIGNED_CHAR ((MPI_Datatype)0x4c000102)
>> #define MPI_BYTE ((MPI_Datatype)0x4c00010d)
>> #define MPI_WCHAR ((MPI_Datatype)0x4c00040e)
>> #define MPI_SHORT ((MPI_Datatype)0x4c000203)
>> #define MPI_UNSIGNED_SHORT ((MPI_Datatype)0x4c000204)
>> #define MPI_INT ((MPI_Datatype)0x4c000405)
>> #define MPI_UNSIGNED ((MPI_Datatype)0x4c000406)
>> #define MPI_LONG ((MPI_Datatype)0x4c000407)
>> #define MPI_UNSIGNED_LONG ((MPI_Datatype)0x4c000408)
>> #define MPI_FLOAT ((MPI_Datatype)0x4c00040a)
>> #define MPI_DOUBLE ((MPI_Datatype)0x4c00080b)
>> #define MPI_LONG_DOUBLE ((MPI_Datatype)0x4c000c0c)
>> #define MPI_LONG_LONG_INT ((MPI_Datatype)0x4c000809)
>> #define MPI_UNSIGNED_LONG_LONG ((MPI_Datatype)0x4c000819)
>> #define MPI_LONG_LONG MPI_LONG_LONG_INT
>> Anyone can tell me what is the meaning of those hex values? and why
>> does the author use them? why do they define "MPI_CHAR" as
>> ((MPI_Datatype)0x4c000101) instead of "char"? thx
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
More information about the mpi-forum