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

Wed Feb 1 02:24:39 CST 2017

Hi Martin, Hi Jeff,

my apologies for taking so long to reply.

As far as I understand and remember we discussed these universal IDs
in both contexts: (1) source ids and (2) event types.

Such an ID would allow a tool to cast a pointer to an info struct to a
specific known struct revealing additional information.

In context of Martin's comment on easy integration with the existing
API, I could imagine a call like

int
MPI_T_event_get_uid(int index, uint64_t* uid);

'uid' being the short form of "universal id". It would be easy to
provide such a call for the other parts (performance/control
variables) of MPI_T as well.

There are some questions arising from this vendor prefixed ID:
1) Which entity issues the prefixes to ensure we don't have duplicates?
2) How would a vendor apply for/request a prefix?
3) Where would the issued prefixes be listed? In the standard?
4) Would the rest of the ID be free for the vendor to use, or would we
need to reserve some bits?

We should use this weeks call to discuss this further.

Cheers,
Marc-Andre

On 22.01.2017 10:55, Schulz, Martin wrote:
> 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
> 
> 
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
> 

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4899 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20170201/e0c64435/attachment-0001.bin>