[mpiwg-p2p] Message matching for tools

[Daniel Holmes]

Hi Jim,

I like that change. On a side note: are we really still calling them 
"info hints" in this context rather than "info assertions"?

Cheers,
Dan.

On 09/02/2016 15:51, Jim Dinan wrote:
> Hi All,
>
> I'm preparing the updated draft of info assertions for a reading in 
> March.  Where did we land on an advice regarding tools?  Do we want 
> advice (1) to users, that they info keys may impact tools and/or (2) 
> to tools that they should check info?
>
> For instance, we could extend the current advice with the following 
> sentence:
>
> Setting info hints on the predefined communicators 
> \const{MPI\_COMM\_WORLD} and \const{MPI\_COMM\_SELF}may have 
> unintended effects, as changes to these global objects may affect all 
> components of the application, including libraries. The usage of info 
> hints may also impact the effectiveness of tools.
>
>  ~Jim.
>
> On Fri, Dec 18, 2015 at 5:24 AM, Marc-Andre Hermanns 
> <hermanns at jara.rwth-aachen.de <mailto:hermanns at jara.rwth-aachen.de>> 
> wrote:
>
>     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 <tel:%2B49%202461%2061%202509> | +49 241
>     80 24381 <tel:%2B49%20241%2080%2024381>
>     Fax: +49 2461 80 6 99753 <tel:%2B49%202461%2080%206%2099753>
>     www.jara.org/jara-hpc <http://www.jara.org/jara-hpc>
>     email: hermanns at jara.rwth-aachen.de
>     <mailto:hermanns at jara.rwth-aachen.de>
>
>
>     _______________________________________________
>     mpiwg-p2p mailing list
>     mpiwg-p2p at lists.mpi-forum.org <mailto:mpiwg-p2p at lists.mpi-forum.org>
>     http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>
>
>
>
> _______________________________________________
> mpiwg-p2p mailing list
> mpiwg-p2p at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p

-- 
Dan Holmes
Applications Consultant in HPC Research
EPCC, The University of Edinburgh
James Clerk Maxwell Building
The Kings Buildings
Peter Guthrie Tait Road
Edinburgh
EH9 3FD
T: +44(0)131 651 3465
E: dholmes at epcc.ed.ac.uk

*Please consider the environment before printing this email.*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20160209/1516b6ae/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20160209/1516b6ae/attachment-0001.ksh>