[mpich-discuss] Existence of something like MPI_Type_compare()?

Eric A. Borisch eborisch at ieee.org
Tue Dec 13 15:17:12 CST 2011


FWIW, I've had good luck using boost::shared_ptr<MPI_Datatype_wrapper>
where MPI_Datatype_wrapper is a tiny class that handles retention (via
MPI_Type_dup) and release (MPI_Type_free) ...

In my own (user-facing) type creation function I cache the function
arguments -> shared_ptr mapping in a fixed-size least-recently-used
container. The shared_ptr is the only thing returned to the calling
program, so no MPI_Type_* calls of any kind are required to return a
cache hit.

Good luck,
 Eric

On Tue, Dec 13, 2011 at 1:56 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Tue, Dec 13, 2011 at 11:40, Rajeev Thakur <thakur at mcs.anl.gov> wrote:
>>
>> Can you not just compare the value of the datatype handle passed by the
>> user with the value you previously stashed away in your cache along with the
>> duped type?
>>
>> One problem is that if the user frees the type and recreates a new one
>> that happens to have the same handle, the handle could now point to a
>> different type. The way to deal with that is to attach an attribute on the
>> user type, with an attribute delete function that will be called when the
>> user frees the datatype. In the delete function, you can clean up the value
>> that is going to get stale in your cache.
>
>
> This would work, but if the user creates and destroys their "unit" type on
> each iteration of some algorithm, I will identify it as being different each
> time (even though it is actually the same) and end up allocating new
> composite types on each iteration. These composite types can be pretty heavy
> (typically MPI_Type_create_indexed_block() with a few thousand entries), so
> it would be a critical storage leak if there were thousands or millions of
> them. I'll have to limit the cache size anyway, but since the point was to
> reuse the types when possible, I would rather compare by value instead of by
> reference.
>
> _______________________________________________
> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
> To manage subscription options or unsubscribe:
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>



-- 
Eric A. Borisch
eborisch at ieee.org

Howard Roark laughed.


More information about the mpich-discuss mailing list