Enh: host_device convenience thunk

Issue #140 new
Dan Bonachea created an issue

Copied from pull request #18:

We could specify convenience classes such as the following, to help generic programming:

namespace upcxx {
struct host_device { // trivial device representing the host
  // implements the important parts of the Device "Concept" from cuda_device:
  //    DefaultConstructible, MoveConstructible, Destructible  
  static const memory_kind kind = memory_kind::host;
  template <typename T>
  using pointer = T*;

  // host_device() {} // trivial non-collective default constructor, constructs a VALID host_device 
  // host_device(host_device &&other) {} // trivial move constructor
  bool is_valid() const { return true; }
  // trivial destructor
  // no destroy() or device_id()
};
struct device_allocator<host_device> { 
  // specialization of device_allocator providing a "thunk" allocator for the shared segment:
  //    DefaultConstructible, MoveConstructible, Destructible
  // device_allocator() {}; // trivial default constructor
  //    constructs a VALID device_allocator<host_device> over the shared segment
  // device_allocator(device_allocator &other) {}; // trivial move constructor                         

  // Member thunks for the corresponding global_ptr<T, memory_kind::host> free functions:
  template <typename T, size_t alignment = alignof(T)> 
  global_ptr<T> allocate(size_t n=1) { return upcxx::allocate<T,alignment>(n); }
  template <typename T> 
  void deallocate(global_ptr<T> g) { return upcxx::deallocate<T>(g); }

  global_ptr<T> to_global_ptr(T *p) { return upcxx::to_global_ptr(p); }
  global_ptr<T> try_global_ptr(T *p) { return upcxx::try_global_ptr(p); }
  T *raw_pointer(global_ptr<T> g) { return g.local(); }

  // trivial destructor                   
};
}

The idea is app code written to be parametric over a upcxx::device_allocator<T> could be passed one of these objects to have it use host memory instead. This might be especially valuable for applications written to optionally use GPUs, where it wouldn't otherwise be possible to instantiate a working device_allocator<Device>.

The user could theoretically construct the thunk above himself, but I don't think we want to encourage user specialization of the upcxx::device_allocator template. It could alternatively live in upcxx-extras/extensions if we don't want to commit to speccing it yet.

Comments (2)

  1. Log in to comment