Hi all,
I put the notes from this morning's meeting on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014-01-23
Kathryn
On Jan 22, 2014, at 3:42 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote:
> Hi all,
>
> This is a reminder about our regular telecon tomorrow Jan 23 at 8 AM Pacific, 11 AM Eastern. As always, the link to the webex is on the main wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools
>
> We plan to talk about Marc-Andre's idea for variable consistency (realms) and possibly talk more on the idea of vector reads that we talked about at the forum face-to-face meeting.
>
> Kathryn
> _________________________________________________________________
> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/
> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>
>
>
>
>
>
>
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
_________________________________________________________________
Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
Hi all,
This is a reminder about our regular telecon tomorrow Jan 23 at 8 AM Pacific, 11 AM Eastern. As always, the link to the webex is on the main wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools
We plan to talk about Marc-Andre's idea for variable consistency (realms) and possibly talk more on the idea of vector reads that we talked about at the forum face-to-face meeting.
Kathryn
_________________________________________________________________
Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
Hi Martin,
> I always expected that if a variable named "foo" exists in two
> processes, it collects the same metric with the same semantics.
Yes, that is what I would hope for, too, but I think as it is written at
the moment a fully standard compliant implementation does not have to
work this way and there seems no viable way of finding out what the
situation is, right?
> When we wrote the paragraph we (or at least I) had in mind that the
> set of variables can be different (i.e., if "foo" exists on A, it
> does not have to exist on B) and the order can be different.
That is what I took from the first sentence in the advice to users,
where it is explicitly stated that number and type of variables can
change even between runs. That is fine, I guess, apart from the other
issues that Michael raised on building a PAPI component.
> Not sure if we can formalize this or if people would go along with
> it, but it would certainly be advantageous for the tools.
It would be a question for the MPI vendors, whether it would impose a
serious restriction on their implementation to say that a name of a
variable should not change semantics for a certain version of the
implementation.
But then again, what does "version" mean and how to define it ... :-/
> However, having said that, I can actually envision scenarios where
> this would be hard to achieve. If you have a heterogeneous system
> (two architectures/networks or MPI bridging GPU and CPU) it may be a
> combination of two separate MPIs (with separate name spaces) or the
> same metric may have different meanings (similar to Flop counts
> having separate meanings on different architectures). I'd be curious
> to hear what our implementors think about that. In the homogeneous
> case, though, I would fully expect some consistency between
> processes.
As Michael pointed out in his reply, the "realm" idea could provide the
means to define namespaces in a way that tools could query. However, I
am still unsure whether something like this is overkill for the
situation or whether it potentially solves only a non-existent problem.
Cheers,
Marc-Andre
> On Jan 10, 2014, at 10:52 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de>
> wrote:
>
>> Dear all,
>>
>> I hope all of you had a good start into the new year.
>>
>> Let me apologize in advance for the lengthy text following.
>>
>> I am currently in the discussion with the developers of the metric
>> modules for Scalasca and Score-P, and I think we need some
>> clarification. Please correct me in my understanding if anything of the
>> following is not correct.
>>
>> Here is the current quote of the advice to users in the ticket PDF:
>>
>> "[...]Further, there is no guarantee that number of variables, variable
>> indices, and variable names are the same across processes."
>>
>> I read the following out of this:
>> A variable indicating a metric X may be called "foo" on one process and
>> "bar" on another.
>>
>> Is that correct?
>>
>> a) How should a tool aggregate and correlate metrics if there is no way
>> on knowing which belong together (after all indices and names are
>> different)?
>>
>> b) Does this allow the namespaces of metrics to overlap?
>> If the variable for metric X is "foo" on one process and "bar" on
>> another. Is the other process allowed to have a variable "foo" that
>> actually reports some different metric? How will a tool get the difference?
>>
>> I know that the new "Advice to implementers" is supposed to clarify
>> this. But I am unsure whether making this a sole "quality of
>> implementation" issue will work for providers of portable tools.
>>
>> Also, with differences among runs, tools like the Cube Algebra (where
>> you can compute averages of multiple measurements) do not work anymore,
>> as Cube will not know whether "foo" of run one correlates to "foo" of
>> run two, rendering the whole tool moot.
>>
>> Cheers,
>> Marc-Andre
>> --
>> Marc-Andre Hermanns
>> German Research School for
>> Simulation Sciences GmbH
>> c/o Laboratory for Parallel Programming
>> 52062 Aachen | Germany
>>
>> Tel +49 241 80 99753
>> Fax +49 241 80 6 99753
>> Web www.grs-sim.de
>>
>> Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
>> Registered in the commercial register of the local court of
>> Düren (Amtsgericht Düren) under registration number HRB 5268
>> Registered office: Jülich
>> Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
>>
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
--
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52062 Aachen | Germany
Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de
Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
Hi all,
as being participant in the initial discussion with Marc-Andre I'd like
to comment on that.
On 01/10/2014 04:27 PM, Martin Schulz wrote:
> Hi Marc-Andre,
>
> I always expected that if a variable named "foo" exists in two processes, it collects the same metric with the same semantics. When we wrote the paragraph we (or at least I) had in mind that the set of variables can be different (i.e., if "foo" exists on A, it does not have to exist on B) and the order can be different. Not sure if we can formalize this or if people would go along with it, but it would certainly be advantageous for the tools.
>
I understood the wording in the same way as Martin, but unfortunately
the advice to users doesn't say anything about semantics, so in a bad
implementation this could actually happen. Although I would have no
problem with having two names for the same information, as long as it is
consistent across all processes.
> However, having said that, I can actually envision scenarios where this would be hard to achieve. If you have a heterogeneous system (two architectures/networks or MPI bridging GPU and CPU) it may be a combination of two separate MPIs (with separate name spaces) or the same metric may have different meanings (similar to Flop counts having separate meanings on different architectures). I'd be curious to hear what our implementors think about that. In the homogeneous case, though, I would fully expect some consistency between processes.
>
Indeed, but here Marc-Andre's proposal with the realms could help (see
his mail from November 14th). We need some deterministic way to
determine which sets of processes offer the same information, otherwise
the MPI_T interface will be pretty hard to use by tools (at least in a
portable way).
-Michael
> Martin
>
>
>
> On Jan 10, 2014, at 10:52 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de>
> wrote:
>
>> Dear all,
>>
>> I hope all of you had a good start into the new year.
>>
>> Let me apologize in advance for the lengthy text following.
>>
>> I am currently in the discussion with the developers of the metric
>> modules for Scalasca and Score-P, and I think we need some
>> clarification. Please correct me in my understanding if anything of the
>> following is not correct.
>>
>> Here is the current quote of the advice to users in the ticket PDF:
>>
>> "[...]Further, there is no guarantee that number of variables, variable
>> indices, and variable names are the same across processes."
>>
>> I read the following out of this:
>> A variable indicating a metric X may be called "foo" on one process and
>> "bar" on another.
>>
>> Is that correct?
>>
>> a) How should a tool aggregate and correlate metrics if there is no way
>> on knowing which belong together (after all indices and names are
>> different)?
>>
>> b) Does this allow the namespaces of metrics to overlap?
>> If the variable for metric X is "foo" on one process and "bar" on
>> another. Is the other process allowed to have a variable "foo" that
>> actually reports some different metric? How will a tool get the difference?
>>
>> I know that the new "Advice to implementers" is supposed to clarify
>> this. But I am unsure whether making this a sole "quality of
>> implementation" issue will work for providers of portable tools.
>>
>> Also, with differences among runs, tools like the Cube Algebra (where
>> you can compute averages of multiple measurements) do not work anymore,
>> as Cube will not know whether "foo" of run one correlates to "foo" of
>> run two, rendering the whole tool moot.
>>
>> Cheers,
>> Marc-Andre
>> --
>> Marc-Andre Hermanns
>> German Research School for
>> Simulation Sciences GmbH
>> c/o Laboratory for Parallel Programming
>> 52062 Aachen | Germany
>>
>> Tel +49 241 80 99753
>> Fax +49 241 80 6 99753
>> Web www.grs-sim.de
>>
>> Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
>> Registered in the commercial register of the local court of
>> Düren (Amtsgericht Düren) under registration number HRB 5268
>> Registered office: Jülich
>> Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
>>
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
--
Michael Knobloch
Institute for Advanced Simulation (IAS)
Jülich Supercomputing Centre (JSC)
Telefon: +49 2461 61-3546
Telefax: +49 2461 61-6656
E-Mail: m.knobloch(a)fz-juelich.de
Internet: http://www.fz-juelich.de/jsc
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Hi Marc-Andre,
I always expected that if a variable named "foo" exists in two processes, it collects the same metric with the same semantics. When we wrote the paragraph we (or at least I) had in mind that the set of variables can be different (i.e., if "foo" exists on A, it does not have to exist on B) and the order can be different. Not sure if we can formalize this or if people would go along with it, but it would certainly be advantageous for the tools.
However, having said that, I can actually envision scenarios where this would be hard to achieve. If you have a heterogeneous system (two architectures/networks or MPI bridging GPU and CPU) it may be a combination of two separate MPIs (with separate name spaces) or the same metric may have different meanings (similar to Flop counts having separate meanings on different architectures). I'd be curious to hear what our implementors think about that. In the homogeneous case, though, I would fully expect some consistency between processes.
Martin
On Jan 10, 2014, at 10:52 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de>
wrote:
> Dear all,
>
> I hope all of you had a good start into the new year.
>
> Let me apologize in advance for the lengthy text following.
>
> I am currently in the discussion with the developers of the metric
> modules for Scalasca and Score-P, and I think we need some
> clarification. Please correct me in my understanding if anything of the
> following is not correct.
>
> Here is the current quote of the advice to users in the ticket PDF:
>
> "[...]Further, there is no guarantee that number of variables, variable
> indices, and variable names are the same across processes."
>
> I read the following out of this:
> A variable indicating a metric X may be called "foo" on one process and
> "bar" on another.
>
> Is that correct?
>
> a) How should a tool aggregate and correlate metrics if there is no way
> on knowing which belong together (after all indices and names are
> different)?
>
> b) Does this allow the namespaces of metrics to overlap?
> If the variable for metric X is "foo" on one process and "bar" on
> another. Is the other process allowed to have a variable "foo" that
> actually reports some different metric? How will a tool get the difference?
>
> I know that the new "Advice to implementers" is supposed to clarify
> this. But I am unsure whether making this a sole "quality of
> implementation" issue will work for providers of portable tools.
>
> Also, with differences among runs, tools like the Cube Algebra (where
> you can compute averages of multiple measurements) do not work anymore,
> as Cube will not know whether "foo" of run one correlates to "foo" of
> run two, rendering the whole tool moot.
>
> Cheers,
> Marc-Andre
> --
> Marc-Andre Hermanns
> German Research School for
> Simulation Sciences GmbH
> c/o Laboratory for Parallel Programming
> 52062 Aachen | Germany
>
> Tel +49 241 80 99753
> Fax +49 241 80 6 99753
> Web www.grs-sim.de
>
> Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
> Registered in the commercial register of the local court of
> Düren (Amtsgericht Düren) under registration number HRB 5268
> Registered office: Jülich
> Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
Dear all,
I hope all of you had a good start into the new year.
Let me apologize in advance for the lengthy text following.
I am currently in the discussion with the developers of the metric
modules for Scalasca and Score-P, and I think we need some
clarification. Please correct me in my understanding if anything of the
following is not correct.
Here is the current quote of the advice to users in the ticket PDF:
"[...]Further, there is no guarantee that number of variables, variable
indices, and variable names are the same across processes."
I read the following out of this:
A variable indicating a metric X may be called "foo" on one process and
"bar" on another.
Is that correct?
a) How should a tool aggregate and correlate metrics if there is no way
on knowing which belong together (after all indices and names are
different)?
b) Does this allow the namespaces of metrics to overlap?
If the variable for metric X is "foo" on one process and "bar" on
another. Is the other process allowed to have a variable "foo" that
actually reports some different metric? How will a tool get the difference?
I know that the new "Advice to implementers" is supposed to clarify
this. But I am unsure whether making this a sole "quality of
implementation" issue will work for providers of portable tools.
Also, with differences among runs, tools like the Cube Algebra (where
you can compute averages of multiple measurements) do not work anymore,
as Cube will not know whether "foo" of run one correlates to "foo" of
run two, rendering the whole tool moot.
Cheers,
Marc-Andre
--
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52062 Aachen | Germany
Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de
Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
Hi all,
Sorry but I am going to cancel our telecon tomorrow, unless someone else wants to lead it and take notes.
Kathryn
________________________________________________________________
Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
