Threads WG Meeting 1 08 2019

(Thanks Ferrol for the notes)

Agenda

Discussion on the tickets/issues : #259, #243

Attendees (Update after the meeting)

• Ferrol (MTSU)
• Tony (SUNY)
• Manjunath Gorentla (Mellanox)
• Naveen (Cray)
• Anshuman, Akhil (NVIDIA)
• Min Si (ANL)
• Md Rahman, Jim, Dave (Intel)

Notes

• CAF - Interoperability update

  • Pull request to open with most of the changes in there

  • Naveen will introduce new fortran interface based on C-binding features of Fortran 2013

    • Similar to Fortran 2008 bindings

    • Changes will occur with respect to argument order on a few APIs, particularly the APIs involving contexts. Rather than being the first argument like C, they will be the last argument.

  • Next meeting Naveen will discuss more regarding CAF interoperatbility

• shmem_malloc_with_hints

  • Github PR #259 was read
  • Questions included:

    • Will this interface support realloc? That is, will the library need to keep enough bookkeeping to properly perform a realloc. There were some issues regarding this and aligned memory in the past.

    • Is the barrier mentioned in the write up a barrier() or a barrier_all() ?

    • There was some discussion regarding the meaning behind the two sets (tables) of hints.

      • The first set seemed to be more aligned with the user having knowledge of the architecture and appropriately selecting a particular memory (i.e., I know the NIC has affinity to a NUMA, allocate memory on that NUMA).

      • The second set seems to be more aligned with the user being unsure regarding the architecture of the system and leaning more on the library (i.e., I trust the library to make the most efficient allocation of memory that will only be used for atomic operations).

    • How will this interface work with accelerator’s memory? Can we allocate memory from different memory kinds and push this into a single symmetric heap?

      • It should be possible to allocate memory and map the memory into the same address space making it possible to have one symmetric heap. Whether or not this is possible with all memory kinds is uncertain.

      • The interfaces used to map the addresses will be discussed more offline.

• Short, brief discussion of the sharp allocator and the extension of OpenSHMEM to support heterogeneous memories was presented

  • Questions included:
    • Was the memory allocated by SharP registered at init? or during runtime?
    • Memory was allocated during runtime and required registration, making the operation heavy weight. However, future allocation operations were lightweight as the heap was already allocated.

• MPI/SHMEM Interoperability

  • Min updated the issue for the github ticket, but did not have enough time to explain the updates.
  • Will pick this up next meeting.