[mpiwg-persistence] [EXTERNAL] Re: Notes from WG meeting 28th May 2019

Grant, Ryan Eric (-EXP) regrant at sandia.gov
Tue May 28 22:34:23 CDT 2019


Everyone,


Here are the changes based on feedback from today. ​There are quite a few changes but overall it is far less text than we had before. I'd appreciate any feedback and any other sets of eyes on this for a sanity check.


Thanks,

Ryan

________________________________
From: HOLMES Daniel <d.holmes at epcc.ed.ac.uk>
Sent: Tuesday, May 28, 2019 7:32 PM
To: Anthony Skjellum; Grant, Ryan Eric (-EXP)
Cc: MPI WG Persistence working Group
Subject: [EXTERNAL] Re: [mpiwg-persistence] Notes from WG meeting 28th May 2019

Hi all,

After further discussion, one of the answers has changed.

Question: how does datatype describe complex layouts?
Answer: it does not - it is the same as I/O with eType == xfer_type and fileType == contig

New answer: the {count, datatype} tuple specifies the type map for a single partition; that interpretation of the proposed parameters permits a straightforward generalisation to MPI_Psendv_init and MPI_Psendw_init, which allow the type map to be different for each partition. For MPI_Psendv_init, the count parameter becomes an array of counts (of length equal to the numPartitions parameter) that gives the type map for the Nth partition via an implicit MPI_Type_contiguous(count_array[N], xfer_type) construction. For MPI_Psendw_init, both the count and data type parameters become arrays (of length equal to the numPartitions parameter) that give the type map for the Nth partition via an implicit MPI_Type_contiguous(count_array[N], type_array[N]) construction. The W version would benefit from an additional of displacements for the same reason as for the existing W functions in MPI. These extension functions permit arbitrary partitioning in future but require a change to the proposed special-case functions.

Note: this new interpretation of the existing parameters for MPI_Psend_init and MPI_Precv_init avoids the possibility of the user giving a number of partitions that does not work with the {count, data type} tuple, e.g.
  numPartitions = 3
  count = 10
  datatype = MPI_Type_contiguous(100, MPI_DOUBLE)
With the previous interpretation of the input parameters (i.e. the {count, data type} tuple specifies the type map for all partitions combined), this means MPI must try to divide 1000 doubles into 3 equally sized partitions, which leads to buffer under-run situations or to mandating some input combinations are erroneous.
With the new interpretation of the input parameters (i.e. the {count, data type} tuple specifies the type map for each partition), this means there are 3 partitions of 1000 doubles, i.e. 3000 doubles in total across all partitions.

This is quite a fundamental change for a no-no vote, so it may result in the proposal being read (again) at the next face-to-face meeting.

Cheers,
Dan.
—
Dr Daniel Holmes PhD
Applications Consultant in HPC Research
d.holmes at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>
Phone: +44 (0) 131 651 3465
Mobile: +44 (0) 7940 524 088
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT
—
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
—

On 28 May 2019, at 18:27, Skjellum, Anthony <Tony-Skjellum at utc.edu<mailto:Tony-Skjellum at utc.edu>> wrote:

Cool — all seem fixable :-)

Anthony Skjellum, PhD
205-807-4968


On May 28, 2019, at 4:25 PM, HOLMES Daniel via mpiwg-persistence <mpiwg-persistence at lists.mpi-forum.org<mailto:mpiwg-persistence at lists.mpi-forum.org>> wrote:

Hi Ryan,

Here are my notes from the WG meeting today:


Define channel - for all usages throughout the spec (existing and proposed).

Example: use variables for tag, dest, etc parameters in the Psend_init call
Example: use variables for tag, dest, etc parameters in the Precv_init call

Example: typo for MPI_Pstart - should be MPI_Start and should not end with brace

Example: typo for &xfer_type in the Psend_init call - use just xfer_type instead
Example: typo for &xfer_type in the Precv_init call - use just xfer_type instead
Example: typo for &request and &i in the Pready call - use just request and i instead
Example: typo for &part in the Pwait call - use just part instead

Question: can partitioned receive match with any other send than the partitioned send it matched with during initialisation? No.

Question: how does datatype describe complex layouts?
Answer: it does not - it is the same as I/O with eType == xfer_type and fileType == contig

Suggestion: add an MPI_Info parameter to both MPI_Psend_init and MPI_Precv_init

Example: typo for amp parallel for (the for is missing)

Example: tasks need to use different values for i in Pready

Suggestion: mandate exactly one call to Pready for each partition between start and wait

Suggestion: partition parameters must be consistent - either int or MPI_Count

Note: there is room for (and potential use-cases for) Psendv_init (Pavan’s case) and Psendw_init (Rich’s case)

Cheers,
Dan.
—
Dr Daniel Holmes PhD
Applications Consultant in HPC Research
d.holmes at epcc.ed.ac.uk<mailto:d.holmes at epcc.ed.ac.uk>
Phone: +44 (0) 131 651 3465
Mobile: +44 (0) 7940 524 088
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT
—
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
—

_______________________________________________
mpiwg-persistence mailing list
mpiwg-persistence at lists.mpi-forum.org<mailto:mpiwg-persistence at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-persistence/attachments/20190529/ce432333/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part.pdf
Type: application/pdf
Size: 215733 bytes
Desc: part.pdf
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-persistence/attachments/20190529/ce432333/attachment-0001.pdf>


More information about the mpiwg-persistence mailing list