MPICH2 folks -- I've a question about MPID_Segment_pack(): In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer. MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer. Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be? -dg
Hi, That is by design. It stops at type boundaries. You can specify an ALL_BYTES flag somewhere in the construction path if you want to have more flexibility (dataloop will be in terms of byte elements and thus you won't have this problem). On iPhone or I'd look exactly where. -- Rob On Aug 6, 2008, at 3:07 PM, David Gingold <[email protected]> wrote:
MPICH2 folks --
I've a question about MPID_Segment_pack():
In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer.
MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer.
Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be?
-dg
It would be nice, though, if that could be selected in a parameter to segment_manipulate instead of at construction time. I'll see what I can find out about that. -d On 08/06/2008 03:29 PM, Rob Ross wrote:
Hi,
That is by design. It stops at type boundaries. You can specify an ALL_BYTES flag somewhere in the construction path if you want to have more flexibility (dataloop will be in terms of byte elements and thus you won't have this problem). On iPhone or I'd look exactly where.
-- Rob
On Aug 6, 2008, at 3:07 PM, David Gingold <[email protected]> wrote:
MPICH2 folks --
I've a question about MPID_Segment_pack():
In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer.
MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer.
Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be?
-dg
Hi, This would be a big pain, because all the piece functions would need to know what behavior was desired, and you'd have to track where in the element you stopped, which the code doesn't do right now (it always stops at an element boundary). -- Rob On Aug 11, 2008, at 3:05 PM, Darius Buntinas wrote:
It would be nice, though, if that could be selected in a parameter to segment_manipulate instead of at construction time. I'll see what I can find out about that.
-d
On 08/06/2008 03:29 PM, Rob Ross wrote:
Hi, That is by design. It stops at type boundaries. You can specify an ALL_BYTES flag somewhere in the construction path if you want to have more flexibility (dataloop will be in terms of byte elements and thus you won't have this problem). On iPhone or I'd look exactly where. -- Rob On Aug 6, 2008, at 3:07 PM, David Gingold <[email protected]> wrote:
MPICH2 folks --
I've a question about MPID_Segment_pack():
In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer.
MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer.
Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be?
-dg
Hmm. What if I used IGNORE_LAST, but specified the actual length in a parameter struct (that's passed to the piece functions). Then the piece function can pack as much as it can, even if it's not a complete basic type, but remembers how much it actually copied so it can pick up from there later. Is there somewhere a piece function can save state like this in the segment (like segment_manipulate does)? Disclaimer: I'm not looking at the code so I may not know what I'm talking about. -d On 08/17/2008 04:28 PM, Rob Ross wrote:
Hi, This would be a big pain, because all the piece functions would need to know what behavior was desired, and you'd have to track where in the element you stopped, which the code doesn't do right now (it always stops at an element boundary). -- Rob
On Aug 11, 2008, at 3:05 PM, Darius Buntinas wrote:
It would be nice, though, if that could be selected in a parameter to segment_manipulate instead of at construction time. I'll see what I can find out about that.
-d
On 08/06/2008 03:29 PM, Rob Ross wrote:
Hi, That is by design. It stops at type boundaries. You can specify an ALL_BYTES flag somewhere in the construction path if you want to have more flexibility (dataloop will be in terms of byte elements and thus you won't have this problem). On iPhone or I'd look exactly where. -- Rob On Aug 6, 2008, at 3:07 PM, David Gingold <[email protected]> wrote:
MPICH2 folks --
I've a question about MPID_Segment_pack():
In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer.
MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer.
Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be?
-dg
there's nowhere to save that "i processed 3 bytes of that last int" information. -- rob On Aug 18, 2008, at 8:16 PM, Darius Buntinas wrote:
Hmm. What if I used IGNORE_LAST, but specified the actual length in a parameter struct (that's passed to the piece functions). Then the piece function can pack as much as it can, even if it's not a complete basic type, but remembers how much it actually copied so it can pick up from there later. Is there somewhere a piece function can save state like this in the segment (like segment_manipulate does)?
Disclaimer: I'm not looking at the code so I may not know what I'm talking about.
-d
On 08/17/2008 04:28 PM, Rob Ross wrote:
Hi, This would be a big pain, because all the piece functions would need to know what behavior was desired, and you'd have to track where in the element you stopped, which the code doesn't do right now (it always stops at an element boundary). -- Rob On Aug 11, 2008, at 3:05 PM, Darius Buntinas wrote:
It would be nice, though, if that could be selected in a parameter to segment_manipulate instead of at construction time. I'll see what I can find out about that.
-d
On 08/06/2008 03:29 PM, Rob Ross wrote:
Hi, That is by design. It stops at type boundaries. You can specify an ALL_BYTES flag somewhere in the construction path if you want to have more flexibility (dataloop will be in terms of byte elements and thus you won't have this problem). On iPhone or I'd look exactly where. -- Rob On Aug 6, 2008, at 3:07 PM, David Gingold <[email protected]
wrote: MPICH2 folks --
I've a question about MPID_Segment_pack():
In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer.
MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer.
Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be?
-dg
participants (3)
-
Darius Buntinas -
David Gingold -
Rob Ross