Vision for the module

[kaschau]

Hey Jonathan

This module looks very promising, great work! I have a few questions about your vision/direction for it.

Based on what I see so far, one should be able to write cupy/numpy agnostic code very easily. As in:

Create "arrays", either on the python side via numpy/cupy, via the kokkos module with kokkos.array, or through a bound C++ function like your generate_views.

If numpy was used, data resides in Host/CudaUVMSpace, if cupy was used data resides on Cuda/UVM space...

or

If kokkos.array/generate_view was used with HostSpace wrap the View with numpy, alternatively cupy if CudaSpace was used.

Do some calculations on the python side and the view data changes, do some calculation with Kokkos and the python side sees it.

That makes writing large scale python code really appealing if a single variable can toggle between HostSpace Kokkos calculation and CudaSpace Kokkos calculation (with heavy calculations done through the C++ Kokkos code)

Is that an accurate summary of, at least one, use case you envision?

Again, awesome stuff, i'll be following along.

kyle

[jrmadsen]

Is that an accurate summary of, at least one, use case you envision?

Yes, your summary is accurate. However, I want to point out that you don't necessarily need to use cupy to wrap the views. You can still use numpy by creating a mirror view:

view = kokkos.array(..., space=kokkos.CudaSpace, ...)

# create mirror on host
mirror = view.create_mirror_view()

# numpy wrapper to the same memory allocation
arr = np.array(mirror, copy=False)

# modify numpy array
arr[0] = ...

# the changes to numpy array 'arr' will be present in 'mirror' since they both reference same memory allocation
# so you can now just deep copy the mirror back into the view
view.deep_copy(mirror)

[kaschau]

Yeah your more recent pushes indicate that a view in CudaSpace are not accessible at all (directly) from within python. When I posed this I was thinking about being able to wrap a KokkosView in CudaSpace with a cupy array, in an identical manner to how a numpy array can wrap a host space view.

Thus, an operation on the cupy array (on the python side) is reflected in the View in CudaSpace. Making the requirement for carrying around the mirror, as well as the deep copy operation unnecessary. But if the mirror<->deep_copy model is required, then I agree, there is no real benefit for wrapping with cupy arrays.

On that note, if a copy of an array is required, is there any plan for supporting subviews? Just thinking ahead about, say applying a boundary condition to an array and updating it to the CudaSpace view without having to copy the entire array. That kind of thing.

[jrmadsen]

But if the mirror<->deep_copy model is required, then I agree, there is no real benefit for wrapping with cupy arrays.

It is not required. You can still use cupy. The mirror <-> deep_copy was just an alternative suggestion since cupy can be another heavyweight dependency.

On that note, if a copy of an array is required, is there any plan for supporting subviews?

Not right now, since you can easily wrap the views with either numpy or cupy, it is a bit superfluous to make that available in python (and it would drive up the compile time even more)

[jrmadsen]

@namehta4