[mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017

[Schulz, Martin]

Hi Jeff,

Don’t get me wrong - I wasn’t proposing to push this onto the long bench and do it after MPI-4. There is no reason to not bring this up in time for MPI 4 or even develop it together. I was just suggesting to decouple this from the actual events ticket for two reason:
- I think the events part is fairly far along and probably easily accepted and I was suggesting to not push it out because of this
- We need a clean retrofit solution anyway to make it work for variables - we can the use it for events as well.

At the end, this is up to Marc-Andre since he is doing the work :)

Martin



> On Jan 20, 2017, at 6:41 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
> My $0.02: we know that there are limitations with the way we've been approaching this stuff for years (over specifying, e.g. PERUSE, which got shot down/shunned, and under specifying leads to tools without any semantic information and implementations that are not incentivized to do anything because the Forum doesn't like "creative" uses of the API, even if they give semantic information to the tools [who are asking exactly for this semantic information] -- e.g., usNIC BTL use of MPI_T variables on a per-interface basis).
> 
> Why not learn from these limitations and propose something better?
> 
> My point: if we're going to do this, do it right.  Let's not have more buyer's remorse after MPI-4 because the new API (still) doesn't give tools any rich and/or semantic information.
> 
> ----
> 
> Keep in mind that I proposed two different ideas:
> 
> 1. The idea of identifying event sources by a (vendor ID, part ID, source ID) tuple
> 2. The idea of a sanctioned extension mechanism
> 
> Note that neither of these are new ideas; they're borrowed from best practices that just happen to be (just barely) outside of the realm of MPI.
> 
> They're still best practices, though.
> 
> 
>> On Jan 20, 2017, at 12:03 AM, Martin Schulz <schulzm at llnl.gov> wrote:
>> 
>> Hi all,
>> 
>> I was thinking about today’s discussion on the tools call and since I won’t be able to join in two weeks, I thought I’d send a follow-up to start a discussion:
>> 
>> I like Jeff’s ideas to provide cross-platform events that are keyed using a vendor ID (or sets of IDs). As Jeff mentioned, it would be cool to see common events in different MPIs if they are built on the same underlying layer. 
>> 
>> Listing to the discussion today, though, I think this would face quite some controversy in the forum and makes the overall problem quite a bit bigger. Also, this functionality seems useful for control and performance variables, for the same reason, and hence it would be good to look for a solution that can also be retrofitted to these variables. A second set of get info calls that translate an MPI specific event/variable ID to a vendor ID could be one option (but just shooting off the hip right now).
>> 
>> I’d therefore suggest to separate the two issues - one ticket to add events in the style that we have already (which seems to be quite acceptable to the forum, at least there weren’t many negative comments) - and then a second ticket on adding vendor IDs to all three MPI_T concepts (again in the same style). This could help MPI_T events in its discussion in the forum and potentially get it passed sooner and it would give us consistency between the three MPI_T concepts. 
>> 
>> What do you all think about this?
>> 
>> Thanks!
>> 
>> Martin
>> 
>> 
>>> On Jan 19, 2017, at 1:15 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
>>> 
>>> Dear all,
>>> 
>>> This is the gentle reminder for this week's call with a session on
>>> *Performance Tools*:
>>> 
>>> Thursday Jan 19, 2017 11 a.m. Eastern Time (*today*)
>>> 
>>> Here is the webex link:
>>> 
>>> https://cisco.webex.com/ciscosales/j.php?MTID=m0fb3e4a68162bff5874849e4700b806a
>>> 
>>> Agenda:
>>> - MPI_T events
>>> 
>>> Cheers,
>>> Marc-Andre
>>> -- 
>>> Marc-Andre Hermanns
>>> Jülich Aachen Research Alliance,
>>> High Performance Computing (JARA-HPC)
>>> Jülich Supercomputing Centre (JSC)
>>> 
>>> Wilhelm-Johnen-Str.
>>> 52425 Jülich
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
>> 
>> ________________________________________________________________________
>> Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>> 
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
> 
> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20170122/96b5d4f7/attachment.bin>