Data abstraction interfaces: Difference between revisions
Jump to navigation
Jump to search
imported>Cnewburn (Created page with "The purpose of this page is to record input on requirements, offerings, and proposals for data abstraction interfaces, as part of the overall HiHAT community effort. * Layers...") |
imported>Cnewburn No edit summary |
||
Line 16: | Line 16: | ||
*** Irregular | *** Irregular | ||
** Representation | ** Representation | ||
*** Declarative approach | |||
**** Semantic properties: accessibility (R/W), size | |||
**** Performance properties: affinity to resources, memory kind, layout | |||
**** Mutable state: pinned, cleared, valid, materialized | |||
*** Layout | *** Layout | ||
**** Distinct from logical handle | **** Distinct from logical handle |
Revision as of 17:42, 20 November 2017
The purpose of this page is to record input on requirements, offerings, and proposals for data abstraction interfaces, as part of the overall HiHAT community effort.
- Layers
- User facing
- Examples: OpenMP, MPI, Sidre, SICM, CHAI, Umpire, ...
- Retargetable plumbing
- Examples: HiHAT User and Common Layer APIs
- User-level implementations
- Examples: memkind, libpmem, cnmem, tcmalloc, jemalloc, cudaMalloc, SCR
- Kernel-level support, and interfaces to that support
- Examples: OS.SICM, mmap, libnuma
- User facing
- Requirements
- Kinds of memory objects
- Regular - simple contiguous arrays, multi-D arrays with stride, block (ref HDF5, MPI data types)
- Irregular
- Representation
- Declarative approach
- Semantic properties: accessibility (R/W), size
- Performance properties: affinity to resources, memory kind, layout
- Mutable state: pinned, cleared, valid, materialized
- Layout
- Distinct from logical handle
- May or may not be changeable without creating a new instance
- Hierarchy
- Provide a formulaic prescription for how data could be partitioned, without overdecomposing it a priori
- Declarative approach
- Asynchrony
- Logical handle is available before async operations complete
- Async operations: virtual alloc, physical materialization, affinitization, pinning, clearing
- Allocation
- Pluggable allocators, e.g. unified, per-thread, same-size
- Operations
- Conflicts: perfect match, partial match, overlapping ranges without conflicts ({.x} and {.y,.z})
- Access: slices, projections
- Kinds of memory objects