--- title: "Read an MPI Message from Its Type Signature and Memory Layout" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/mpi-derived-datatype-signature-extent-message-layout" last-updated: "2026-10-21" --- # Read an MPI Message from Its Type Signature and Memory Layout Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. For a typed MPI exchange, count and datatype describe an ordered sequence of basic values. The type map locates those values in local memory; extent sets the spacing between repeated datatype instances. A receiver can place the same sequence into a different layout. Neither extent nor the addressed memory span establishes transmitted byte count, internal copying or performance. ## Read the type contract before the byte total MPI's type map pairs each basic datatype with a byte displacement. Removing the displacements leaves the type signature: the ordered sequence of basic types. The order comes from the map, not from sorting memory addresses. MPI permits displacements that are nonmonotonic, although the example below uses increasing offsets. Consider an ordinary typed point-to-point exchange whose message selection is already resolved. Its corresponding basic types must match, and the actual variables at both ends must match their declared types. This is separate from asking where each process stores the values. The explanation follows MPI 4.1, dated November 2, 2023, rather than asserting behavior for an unidentified installed implementation. The practical question is whether the receiver's type sequence can accept the sender's values and whether each local layout addresses the intended storage. A proposal that supplies only a byte total leaves both questions open. References: [MPI1](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node96.htm), [MPI4](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node64.htm) ## MPI-6: three datatype instances select six values Worked case MPI-6 is wholly fictional. Stipulate a supported, usable datatype with two MPI_DOUBLE entries, at byte displacements 0 and 16, a lower bound of 0 and an explicitly assigned extent of 32 bytes. The send count is 3. For this example only, each local DOUBLE representation occupies 8 bytes at both processes. All selected locations contain correctly typed values, are valid and do not overlap. These are explanatory premises, not constructed code or an observed transfer. One datatype instance contributes two basic values. Count 3 repeats that instance at base offsets 0, 32 and 64. Adding the two entry displacements at each base selects byte offsets 0 and 16; 32 and 48; then 64 and 80. Thus the communicated type sequence contains six MPI_DOUBLE entries, even though the send count is three. Imagine that those six locations contain, in that order, the values 11, 12, 21, 22, 31 and 32. The first instance supplies 11 and 12, the second supplies 21 and 22, and the third supplies 31 and 32. The spaces between their representations contribute no additional selected values. The explicit extent is a premise with a purpose: it controls where the next instance starts. Replacing 32 with 24 because the first two values fit within 24 bytes would put the second instance at offset 24 instead of 32. That would describe different addresses while leaving the basic-value count unchanged. References: [MPI2](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node103.htm), [MPI3](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node107.htm), [MPI5](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf) ## Separate 48 value bytes, an 88-byte span and 96 bytes of repetition spacing The selected value representations total 6 × 8 = 48 bytes. Their inclusive byte intervals are 0–7, 16–23, 32–39, 48–55, 64–71 and 80–87. This is a local representation-byte calculation under the stipulated 8-byte premise. The smallest interval containing all those entries runs from offset 0 through 87, so its span is 88 bytes. That interval includes five unselected 8-byte gaps: 48 selected bytes plus 40 gap bytes. A span describes how far the selected storage reaches; it does not say that every intervening byte belongs to the message. Count × extent is 3 × 32 = 96 bytes. Offset 96 is where a fourth instance would begin. The third instance's last value ends at 87, leaving offsets 88–95 outside the selected entries. Those eight trailing bytes explain why 96 exceeds the 88-byte addressed span. Consequently, 96 is neither the message's wire-byte count nor a required buffer-allocation size. In this particular base-zero layout, a contiguous storage region covering offsets 0–87 would cover all selected byte intervals; an actual program must also satisfy its language's object, type and address-validity rules. More generally, extent alone does not identify the selected addresses or prove their validity. Likewise, 48 is the sum of local value representations, not a measured transport length. The three quantities answer different questions: how much selected value storage, how wide an address interval, and the boundary after three 32-byte instance slots. References: [MPI2](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node103.htm), [MPI3](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node107.htm), [MPI5](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf) ## A contiguous receiver can accept the same six typed values Stipulate a matching receive with capacity for six contiguous MPI_DOUBLE values. With the receiver's stipulated 8-byte representations, their starting offsets are 0, 8, 16, 24, 32 and 40. After a successful transfer in this fictional case, those locations hold 11, 12, 21, 22, 31 and 32 respectively. The sender's count is 3 for a two-entry derived datatype; the receiver's count can be 6 for the basic MPI_DOUBLE datatype. The different counts and displacements are compatible because the corresponding basic-type sequences match. The receiver needs no matching holes or 32-byte repetition spacing. Receive count specifies capacity, so a receive may provide more matching entries than this message uses. Equal total capacities are not required, but the incoming sequence must fit and its corresponding types must match. This example uses an exact six-entry capacity to keep placement visible. A different basic-type sequence does not become compatible merely because its local representations also total 48 bytes. This discussion concerns typed values; MPI's separately defined byte-oriented and packed-data cases have their own rules. Padding omitted from the type map is not another typed value to be placed at the receiver. References: [MPI3](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node107.htm), [MPI4](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node64.htm) ## Keep each local representation attached to its own interface The related PyTorch views-and-strides article explains how a local tensor addresses shared storage. The PointCloud2 layout article explains a message's fields and row padding. Their layout descriptions can inform a handoff, but neither supplies this MPI sender/receiver type contract. When an application moves between such representations, ask its software owner which values and ordering cross the interface, how the supplied MPI datatype addresses them, and what layout the receiving consumer expects. Matching six DOUBLE entries preserves their communicated sequence; it does not, by itself, establish tensor dimensions, coordinate units or the application meaning of each entry. For MPI-6, saying six values in order is more informative than saying 96 bytes of data. It still needs the application meaning of 11, 12, 21, 22, 31 and 32 before a consumer can interpret them correctly. ## Separate a valid type description from evidence of data movement MPI 4.1 leaves the implementation a choice: it may pack selected data into a contiguous buffer before transmission or collect the data directly from its existing locations. A derived datatype expresses the layout without requiring the application to describe it as a contiguous message buffer. It does not promise that internal copies disappear. Adding an eager, rendezvous or UCX label to MPI-6 supplies no missing copy count or elapsed time. Use the related UCX article for its separate question about arrival notification and payload availability; those API observations cannot be assigned automatically to this MPI exchange. The related NCCL all-reduce acceptance article concerns evidence from completed collectives, rather than validation of this fictional example. A useful technical explanation therefore identifies the sending and receiving count/datatype descriptions, the expanded basic-type sequence, local representation assumptions and selected addresses. If it also claims reduced copying or higher performance, request evidence for that actual implementation, memory arrangement and completed work. Applied to MPI-6, a statement that count 3 communicates only three DOUBLE values is wrong. A statement that 96 bytes must travel confuses repetition spacing with message contents. A statement that the contiguous receiver is incompatible because its offsets differ confuses local layout with type matching. Resolving those errors establishes the description's meaning; an actual runtime result needs its own evidence. References: [MPI1](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node96.htm), [MPI3](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node107.htm), [MPI5](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf) ## Carry a separate physical requirement into the cabling scope If the selected cluster also needs physical links installed, the related Structured Cabling & Fiber Installation service and project inquiry provide the appropriate next step. Share approved endpoints and routes, specified assemblies, the appointed materials supplier and required labels and connection records. The physical installation and checks need their own agreed scope; MPI programming, runtime integration and application validation remain with the appointed software and platform team. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [MPI1 — MPI Forum: Derived Datatypes — MPI 4.1 hosted HTML](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node96.htm). Checked 2026-10-20. Defines type maps and signatures and leaves packing versus direct collection to the implementation. The hosted HTML labels itself unofficial, dated November 2, 2023, generated November 19, 2023. - [MPI2 — MPI Forum: Extent and Bounds of Datatypes — MPI 4.1 hosted HTML](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node103.htm). Checked 2026-10-20. Explains explicit bounds and extent as the stride for repeated instances. Useful for separating repetition spacing from selected-value storage; part of the same unofficial hosted HTML edition. - [MPI3 — MPI Forum: Use of General Datatypes in Communication — MPI 4.1 hosted HTML](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node107.htm). Checked 2026-10-20. Explains count repetition, signature-based type matching, receive capacity and padding semantics. Local displacements may differ between sender and receiver. - [MPI4 — MPI Forum: Type Matching Rules — MPI 4.1 hosted HTML](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node64.htm). Checked 2026-10-20. Distinguishes typed communication, byte-oriented communication and packed data, and requires the actual variables to match the declared typed entries. - [MPI5 — MPI Forum: MPI 4.1 standard — general datatype communication and valid addresses](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report.pdf). Checked 2026-10-20. Official November 2, 2023 PDF, sections 5.1.11–5.1.12, printed pages 158–162: repetition address formula, receive capacity and valid-address constraints. Its section numbering differs from the unofficial hosted HTML. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Describes separately agreed physical fiber and copper installation, labels and connection records using customer-furnished or separately sourced materials. ## Related Leviathan resources - [Local tensor views, strides and shared storage](/articles/pytorch-tensor-views-strides-shared-storage) - [PointCloud2 fields, point strides and row padding](/articles/robotics-ai-pointcloud2-field-layout-row-padding) - [UCX active-message arrival and payload availability](/articles/ucx-active-message-eager-rendezvous-payload) - [NCCL all-reduce evidence and acceptance scope](/articles/nccl-all-reduce-validation-acceptance) - [Structured cabling and physical connection records](/services/structured-cabling) - [Discuss a separately scoped physical cabling project](/contact?service=structured-cabling&from=%2Farticles%2Fmpi-derived-datatype-signature-extent-message-layout) ## Discuss the physical connection package If physical cabling is part of your project, share the approved endpoints, routes, specified assemblies and required handoff records to discuss scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/mpi-derived-datatype-signature-extent-message-layout)