“Where all the cool kids hang out”. The Big Issue:. Counts Larger Than . 2. 31. Counts are expressed as “. int. ” / “INTEGER”. Usually limited to . 2. 31. Propose a new type: . MPI_Count. ID: 459547 Download Presentation
Download Presentation - The PPT/PDF document "Backward Compatibility WG" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation on theme: "Backward Compatibility WG"— Presentation transcript:
Backward Compatibility WG
“Where all the cool kids hang out”
The Big Issue:Counts Larger Than 231
Counts are expressed as “int” / “INTEGER”Usually limited to 231Propose a new type: MPI_CountCan be larger than an int / INTEGER“Mixed sentiments” within the ForumIs it useful? Do we need it? …oy!
buf, int count, …)
Do we need MPI_Count?
Some users have asked for itTrivially send large msgs.No need to make a datatypePOSIX went to size_tWhy not MPI?Think about the future:Bigger RAM makes 231 relevantDatasets getting largerDisk IO getting largerCoalescing off-node msgs.
Very few usersAffects many, many MPI API functionsPotential incompatibilitiesE.g., mixing int and MPI_Count in the same application
Ok, so how to do it? (1 of 2)
Use MPI_Count only for new MPI-3 routinesChange C bindingsRely on C auto-promotionOnly fix MPI IO functionsWhere MPI_BYTE is usedNew, duplicate functionsE.g., MPI_SEND_LARGE
confusing to users
Bad for Fortran, bad
for C OUT params
confusing to users
What about sizes,
ags, ranks, …
Ok, so how to do it? (2 of 2)
Fully support large datatypesE.g., MPI_GET_COUNT_LONGCreate a system for API versioningUpdate all functions to use MPI_CountMake new duplicate functions with MPI_Count, MPI_Tag, MPI_Size, …E.g., MPI_SEND_EX