On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan@gmail.com> wrote:

We're calling the proposal "info assertions", but the standard still refers to them as "hints".

Reading the proposed change again, I think it might be helpful (and more fair to tools) to say why info could impact tools:

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 some info hints may allow the MPI library to change its behavior and, as a result, impact the effectiveness of tools.

~Jim.
On Tue, Feb 9, 2016 at 12:38 PM, Daniel Holmes <dholmes@epcc.ed.ac.uk> wrote:
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@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 | +49 241 80 24381
Fax: +49 2461 80 6 99753
www.jara.org/jara-hpc
email: hermanns@jara.rwth-aachen.de

_______________________________________________
mpiwg-p2p mailing list
mpiwg-p2p@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
_______________________________________________
mpiwg-p2p mailing list
mpiwg-p2p@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@epcc.ed.ac.uk *Please consider the environment before printing this email.*
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
mpiwg-p2p mailing list
mpiwg-p2p@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
_______________________________________________
mpiwg-p2p mailing list
mpiwg-p2p@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p