Skip to content

Add dparray #192

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Dec 7, 2020
Merged

Add dparray #192

merged 15 commits into from
Dec 7, 2020

Conversation

PokhodenkoSA
Copy link
Contributor

@PokhodenkoSA PokhodenkoSA commented Dec 1, 2020

This code is from #184 placed in common branch.

From #192 (comment):

  • Doc-strings for the new class and the new module should be added.

@vlad-perevezentsev
Copy link
Collaborator

Fixed comments @oleksandr-pavlyk :
#184 (review)
#184 (review)
#184 (review)

Warning and error @PokhodenkoSA (#184 (comment) ) did not find after making changes.

Commands for the conda virtual environment:
conda create -n dpctl-dev python=3.7 -c http://fxsatmac02.an.intel.com:8091
conda install cython -c http://fxsatmac02.an.intel.com:8091
conda install numpy -c http://fxsatmac02.an.intel.com:8091
conda install cmake -c http://fxsatmac02.an.intel.com:8091
export ONEAPI_ROOT=/opt/intel/oneapi
source /opt/intel/oneapi/compiler/latest/env/vars.sh
python setup.py develop

@PokhodenkoSA
Copy link
Contributor Author

Please, format code with black formatter.

return self

def __array_ufunc__(self, ufunc, method, *inputs, **kwargs):
if method == "__call__":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to also handle method="accumulate" , "reduce", "reduceat", "outer"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a TODO and open a ticket to track this future work.

… MemInfo. We'll have to add __sycl_usm_array_interface__ property to Numba objects to get this equivalent behavior without this dependency in the wrong direction.
@diptorupd
Copy link
Contributor

one general comment; I want to add the new dparray class under dpctl.dptensor.dparray sub module. @oleksandr-pavlyk suggested that we can have other types of tensors defined in dpctl later and it makes sense to keep all of them in one place under a dptensor sub module.

Comment on lines 31 to 38
def test_dparray_through_python_func(self):
def func_operation_with_const(dpctl_array):
return dpctl_array * 2.0 + 13

C = self.X * 5
dp_func = func_operation_with_const(C)
self.assertIsInstance(dp_func, dparray.ndarray)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this test is deleted?
@vlad-perevezentsev

@PokhodenkoSA
Copy link
Contributor Author

PokhodenkoSA commented Dec 3, 2020

add the new dparray class under dpctl.dptensor.dparray sub module

@vlad-perevezentsev Please, make it in separate PR.

Copy link
Contributor Author

@PokhodenkoSA PokhodenkoSA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@PokhodenkoSA
Copy link
Contributor Author

add the new dparray class under dpctl.dptensor.dparray sub module

@vlad-perevezentsev Please, make it in separate PR.

#200

return self

def __array_ufunc__(self, ufunc, method, *inputs, **kwargs):
if method == "__call__":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a TODO and open a ticket to track this future work.

@oleksandr-pavlyk
Copy link
Contributor

oleksandr-pavlyk commented Dec 4, 2020

  • We should try to merge PRs Add dparray #192 and Add the new dparray class under dpctl.dptensor.dparray #200 into a single PR before moving on, these PRs are interdependent.

  • In dpctl/dptensor/__init__.py we should avoid doing from .dparray import * because it pulls the entire namespace of NumPy. Instead we should do from .dparray import ndarray as ndarray_USMShared. It would best reflect implementation if dparray.py is renamed to _ndarray_subclass.py.

  • Tests need to be adjusted accordingly.

  • Doc-strings for the new class and the new module should be added.

  • I will work on __array_ufunc__ in a separate PR.

@DrTodd13
Copy link
Contributor

DrTodd13 commented Dec 4, 2020

We should try to merge PRs #192 and #200 into a single PR before moving one, these PRs are interdependent.

In dpctl/dptensor/__init__.py we should avoid dong from .dparray import * because it pull the entire namespace of NumPy.
Instead we should do from .dparray import ndarray as ndarray_USMShared.

It would best reflect implementation is dparray.py is renamed to _ndarray_subclass.py.

I would like a name that reflects that it can be imported as a full numpy replacement. "dparray" doesn't quite capture that but "_ndarray_subclass" I think could even more so give the wrong impression. At some point we want to call dpnp from there so you're going to get much more than just an ndarray replacement.


# Tell Numba to not treat this type just like a NumPy ndarray but to propagate its type.
# This way it will use the custom dparray allocator.
__numba_no_subtype_ndarray__ = True
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DrTodd13 Do we really need this extra attribute? Can we not use the facts that the array is a subclass of NumPy.ndarray and it defines the __sycl_usm_array_interface__ to recognize this class inside Numba?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Numba is currently made to treat Numpy.ndarray subclasses as if they were Numpy.ndarrays. Therefore, we can't just check for whether it is a ndarray subclass to keep those types separate without breaking backwards compatibility.

Also, you might want to keep types separate even if you don't need a special allocator. So, for generality, we shouldn't specialize on something allocator or USM-specific inside Numba.

@diptorupd
Copy link
Contributor

We should try to merge PRs #192 and #200 into a single PR before moving one, these PRs are interdependent.
In dpctl/dptensor/__init__.py we should avoid dong from .dparray import * because it pull the entire namespace of NumPy.
Instead we should do from .dparray import ndarray as ndarray_USMShared.
It would best reflect implementation is dparray.py is renamed to _ndarray_subclass.py.

I would like a name that reflects that it can be imported as a full numpy replacement. "dparray" doesn't quite capture that but "_ndarray_subclass" I think could even more so give the wrong impression. At some point we want to call dpnp from there so you're going to get much more than just an ndarray replacement.

@diptorupd diptorupd closed this Dec 5, 2020
@PokhodenkoSA
Copy link
Contributor Author

PokhodenkoSA commented Dec 5, 2020

@diptorupd Why did you close this PR? What is the plan for it now?
@vlad-perevezentsev spend significant part of the week to prepare this PR to merge.
#200 was targeted to merge to #192.

@diptorupd
Copy link
Contributor

@PokhodenkoSA not sure when/what I did. Must have accidentally clicked wrong button.

@diptorupd diptorupd reopened this Dec 7, 2020
Remove `include dparray.py`
@PokhodenkoSA
Copy link
Contributor Author

PokhodenkoSA commented Dec 7, 2020

Not necessary. #200 could be merged later. #200 depends on #192. #200 is independent.
Now numba and numba-dppy has PR which expects dpctl.dparray exists. It should be updated too. I would like to move step by step and do not add dptensor module until we have nothing to add also.
In any case we can do in dpctl/__init__.py replase from . import dparray with from .dptensor import dparray and propose clinents to use from dpctl import dparray.

@oleksandr-pavlyk oleksandr-pavlyk mentioned this pull request Dec 7, 2020
diptorupd added a commit that referenced this pull request Dec 7, 2020
This PR contains all the changes in #192, #200. I will close those two PRs after merging this one. Pending issues to improve the dparray implementation are to be addressed as follow up PRs. Thanks @DrTodd13 @oleksandr-pavlyk @vlad-perevezentsev for working on this PR.
@diptorupd diptorupd merged commit 44bbe03 into master Dec 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants