[mpiwg-p2p] Message matching for tools
Daniel Holmes
dholmes at epcc.ed.ac.uk
Tue Feb 9 16:44:23 CST 2016
Hi George,
However, the effect on tools is not limited to global objects such as
the predefined communicators - the semantics are changed for *any*
communicator on which these info assertions are set. Your "and tools"
bit is therefore necessary but not sufficient.
I believe Jim has now changed the wording of the sentence you are
concerned about back to a previous version, i.e. "The usage of info
hints may also impact the effectiveness of tools." Does that alleviate
your concern?
Cheers,
Dan.
On 09/02/2016 22:36, George Bosilca wrote:
> Sorry to jump in the middle (or the end) of the discussion. From my
> "MPI user" point of view, the last part of the proposed advice is
> unsettling.
>
> "The usage of some info hints may allow the MPI library to change its
> behavior and, as a result, impact the effectiveness of tools."
>
> seems to have a broader scope, and includes application developers,
> when the most obvious target should have been tools developers. I
> think removing the last part and emphasizing tools and libraries,
> makes a more clear point.
>
> "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 and tools."
>
> George.
>
>
> On Tue, Feb 9, 2016 at 8:02 PM, Jim Dinan <james.dinan at gmail.com
> <mailto:james.dinan at 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 at epcc.ed.ac.uk <mailto:dholmes at 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 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
>> <mailto: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 <tel:%2B44%280%29131%20651%203465>
> E:dholmes at epcc.ed.ac.uk <mailto:dholmes at 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 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 <mailto: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/55d7e5d6/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/55d7e5d6/attachment-0001.ksh>
More information about the mpiwg-p2p
mailing list