-
Notifications
You must be signed in to change notification settings - Fork 0
notes 2017 07 31
Dan Holmes
Jeff Hammond
Atsushi Hori
Wesley Bland
Sayantan Sur
-
the new datatypes (e.g. for FP16) proposal (issues #65 & #66 on git)
Jeff - reductions using pure FP16 throughout will likely suck - MPI needs to allow FP32 operations.
Atsushi - language-independent types/type names a good idea but (from Bill) there may be unavoidable language dependencies?
Jeff - IEEE defines storage and operation, define user can only pass in correct stuff. Unless HW uses non-IEEE interchange storage then compiler must expose IEEE standard storage and MPI is OK to mandate it. Alternative is software floating-point conversions/operations => madness.
Atsushi - MPI I/O binary representations includes “native” and “IEEE”.
Dan - those INFO keys are mostly ignored?
Jeff - will implement in BigMPI. 5 standardised type of storage/operation/etc. Need to be specific about what MPI needs/requires/ignores.
Atsushi - currently need to specify MPI_FLOAT in C but MPI_REAL4 in Fortran for the same thing. New IEEE types would harmonise that.
Jeff - can use Fortran type names in C and vice versa.
Dan - MPI Standard talks about representation conversion vs type conversion.
Atsushi - MPI Standard (section 3.3.1) send and receive must have identical type names otherwise the program is erroneous.
-
the INFO GET/SET problem (issue #63 on git)
Consensus that this issue is ready to vote on at next face-to-face meeting.
-
the Allocating Receive & Freeing Send extension (#32 on git)
Derived user-defined datatypes cause issues for these operations. Specifically, MPI would need to allocate memory covering the full extent of the datatype not just its length or the amount of data it describes.
Jeff presented the use-case of user packing into a buffer that can be ownership-passed to another rank that the user unpacks. User (un-)packing could be more efficient than MPI, e.g. OpenCL, cache-tiling, multi-threaded, etc.
DONM: Mon 14th August 2017