[mpiwg-p2p] Message matching for tools

Marc-Andre Hermanns hermanns at jara.rwth-aachen.de
Fri Dec 18 04:24:57 CST 2015


Hi Jeff,

>     at the moment we don't handle MPI_THREAD_MULTIPLE at all. But we want
>     to get there ;-)
> 
> 
> You should vote for endpoints, as this may help you out here,
> particularly if users start mapping endpoints 1:1 w/ threads.

That would certainly ease things for us in these situations.
Unfortunately endpoints force use to adapt other infrastructure in our
measurement system.

>     b) Creating a derived datatype on the fly to add tool-level data to
>     the original payload may induce a large overhead in practically
>     _every_ send & receive operation and perturb the measurement.
> 
> 
> You should evaluate this experimentally.  I wrote a simple test
> (https://github.com/jeffhammond/BigMPI/blob/master/test/perf/typepiggy.c)
> and measured 1.5 us per call of overhead to create a datatype.  That
> is not significant except for very small messages.

Thanks for the pointer. You are right. I should evaluate this further.
1.5us does indeed seem tolerable. I wonder how the influence of the
derived datatype is on overall messaging performance, though.

This is also something I should evaluate in the process.

Cheers,
Marc-Andre

-- 
Marc-Andre Hermanns
Jülich Aachen Research Alliance,
High Performance Computing (JARA-HPC)
Jülich Supercomputing Centre (JSC)

Schinkelstrasse 2
52062 Aachen
Germany

Phone: +49 2461 61 2509 | +49 241 80 24381
Fax: +49 2461 80 6 99753
www.jara.org/jara-hpc
email: hermanns at jara.rwth-aachen.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4899 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151218/ddb87b58/attachment-0001.bin>


More information about the mpiwg-p2p mailing list