[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