Backward compatibility wg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 6

Backward Compatibility WG PowerPoint PPT Presentation


  • 40 Views
  • Uploaded on
  • Presentation posted in: General

Backward Compatibility WG. “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 Can be larger than an int / INTEGER “Mixed sentiments” within the Forum

Download Presentation

Backward Compatibility WG

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Backward compatibility wg

Backward Compatibility WG

“Where all the cool kids hang out”


The big issue counts larger than 2 31

The Big Issue:Counts Larger Than 231

  • Counts are expressed as “int” / “INTEGER”

    • Usually limited to 231

  • Propose a new type: MPI_Count

    • Can be larger than an int / INTEGER

  • “Mixed sentiments” within the Forum

    • Is it useful? Do we need it? …oy!

MPI_SEND(void *buf, int count, …)

MPI_SEND(void *buf, MPI_Count count, …)


Do we need mpi count

Do we need MPI_Count?

YES

NO

Very few users

Affects many, many MPI API functions

Potential incompatibilities

E.g., mixing int and MPI_Count in the same application

  • Some users have asked for it

  • Trivially send large msgs.

    • No need to make a datatype

  • POSIX went to size_t

    • Why not MPI?

  • Think about the future:

    • Bigger RAM makes 231relevant

    • Datasets getting larger

    • Disk IO getting larger

    • Coalescing off-node msgs.


Ok so how to do it 1 of 2

Ok, so how to do it? (1 of 2)

  • Use MPI_Count only for new MPI-3 routines

  • Change C bindings

    • Rely on C auto-promotion

  • Only fix MPI IO functions

    • Where MPI_BYTE is used

  • New, duplicate functions

    • E.g., MPI_SEND_LARGE

Inconsistent,

confusing to users

Bad for Fortran, bad

for C OUT params

Inconsistent,

confusing to users

What about sizes,

tags, ranks, …oy!


Ok so how to do it 2 of 2

Ok, so how to do it? (2 of 2)

Forum has hated

every proposal

Technically makes

current codes invalid

  • Fully support large datatypes

    • E.g., MPI_GET_COUNT_LONG

  • Create a system for API versioning

  • Update all functions to use MPI_Count

  • Make new duplicate functions with MPI_Count, MPI_Tag, MPI_Size, …

    • E.g., MPI_SEND_EX

Might be ok…?

Rip the band-aid off!

Preserves backward

Compatibility 


Mpi backwards compatibility wg

MPI Backwards Compatibility WG

“Count on us to find a solution”


  • Login