-
Notifications
You must be signed in to change notification settings - Fork 20
view semantics
This is to track the incremental development of the "view" variant of the fk::vector type which partially addresses #47. These vectors exactly duplicate the semantics of their original "owner" counterparts, with the following exceptions:
- They are a view into some other owning vector's memory, and so do not store any P elements themselves
- They can only exist during their corresponding owner fk::vector's lifetime. The program will terminate with an error if an owner is destroyed while views still exist.
- They can only be created from an existing owning fk::vector/matrix or an existing view fk::vector/matrix
- Owners and views can be arbitrarily interchanged as operands to all operations supported by owners, and when an fk::vector is returned, it is owning.
- An owner cannot be resized (or concatenated, e.g.) while any views derived from it exist. Views cannot be resized, concatenated, etc.
- Owners and views can be compared (
==,!=,<) to each other. This happens by value; the type is not taken into account. - Owners can not be implicitly created from views, in order to avoid unintentional memory allocations.
- Converting move operations are possible, but disabled in order to maintain better general type safety and fewer surprises. compromise to keep converting copy operations which can be called explicitly, but are not used implicitly by the compiler since they are for different types
fk::vectors are owning by default, so no client code needs to change or specify the new template parameter unless a view is being declared. This implies that all of the current tests are only testing the owning variant (since they don't specify).
We will need to have certain members behave differently, or have differing availability. SFINAE is being used here, and the required corresponding explicit instantiations become way too cumbersome, so we abandon those for tensors right now.
(from this -->) owner<P> view<P>
(get this) -----------------------------------------------------------
| | |
V | copy ctor (yes) | copy ctor (yes *2)
owner<P> | copy assign (yes) | copy assign (yes *2)
| move ctor (yes) | move ctor (no *4)
| move assign (yes) | move assign (no *4)
| |
|---------------------------|-----------------------------
| |
| copy ctor (yes *1) | copy ctor (yes)
view<P> | copy assign (yes *2) | copy assign (yes)
| move ctor (no *4) | move ctor (yes)
| move assign (no *4) | move assign (yes)
| |
(from this -->) owner<PP> view<PP>
(get this) -----------------------------------------------------------
| | |
V | copy ctor (yes) | copy ctor (yes *2)
owner<P> | copy assign (yes) | copy assign (yes *2)
| move ctor (no *4) | move ctor (no *4)
| move assign (no *4) | move assign (no *4)
| |
|---------------------------|-----------------------------
| |
| copy ctor (no *3) | copy ctor (no *3)
view<P> | copy assign (yes *2) | copy assign (yes *2)
| move ctor (no *4) | move ctor (no *4)
| move assign (no *4) | move assign (no *4)
| |
*1. this is mimicked by our delegating constructor, but is not found by the
compiler as a true copy constructor (e.g. does not work for std containers).
*2. this is mimicked by the converting constructor/assignment. Since the types
differ, the compiler doesn't pick them up for internal usage.
*3. this would require creating a new owner corresponding to the new view<PP>.
*4. rule 8
other comments:
- no creating owners from views at all (rule 7)
- no converting moves, but allow converting (precision) copies as a
compromise (rule 8). Still no converting copies on memory type (rule 7).
An additional template argument has been added to tensors, resource. Resource is an enumerated type with either device or host value. The default value for tensors is host, which indicates that the tensor's underlying memory is allocated in CPU RAM. device tensors are allocated in accelerator RAM when the appropriate build option is set (ASGARD_USE_CUDA, for now, although we anticipate support for vendors beyond NVIDIA). If this option is not set, device tensors fall back to CPU RAM allocation. Additionally, device tensors have a restricted API; most tensor member functions are disabled. fast_math functions do accept device tensor arguments, however, to enable BLAS functionality on accelerators.
All of the above view semantic rules apply to device and host owners/views. But, a view's resource type must match that of its owner. That is, device views can only be created from device owners, and host views can only be created from host owners.