Skip to content
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

[WIP] Expose cumlHandle (+ other goodies!) into cython world #331

Closed
wants to merge 35 commits into from

Conversation

teju85
Copy link
Member

@teju85 teju85 commented Mar 14, 2019

This PR exposes cumlHandle into the cython world, over-and-above @jirikraus's work in PR #247 .
Additionally, this also proposes for a Base class to be inherited by all ML algos. Such base class will go a long way in reducing code duplication across cuML python interface.

I've used PCA as an example to demonstrate the cumlHandle + Base class related updates. The hope is that all of us can use this as an example to update other algos too (including the new ones).

Things addressed in this PR:

  1. Update the c++ interface of PCA to expose cumlHandle
  2. Join the cython and c++ interfaces after this change
  3. Add a developer guide from the python side
  4. Expose setAllocator methods for the cumlHandle class into cython world
  5. For all the affected methods (only which PCA calls today!), show how to use deviceAllocator instead of the existing 'DeviceAllocator` class.

@dantegd dantegd added 2 - In Progress Currenty a work in progress proposal Change current process or code Cython / Python Cython or Python issue labels Mar 14, 2019
Copy link
Contributor

@jirikraus jirikraus left a comment

Choose a reason for hiding this comment

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

I can't really provide feedback on the python side of this. I hope my comments are still useful.

@GPUtester
Copy link
Contributor

Can one of the admins verify this patch?

@teju85
Copy link
Member Author

teju85 commented Mar 19, 2019

@jirikraus I'd like to particularly bring your attention to my previous commit #000176b. I have migrated the default*Allocator classes inside of ml-prims! Reason being, I'd like to deprecate the existing DeviceAllocator class inside ml-prims and use defaultDeviceAllocator inside unit-tests of ml-prims. Do you have any concerns with this migration?

@jirikraus
Copy link
Contributor

@jirikraus I'd like to particularly bring your attention to my previous commit #000176b. I have migrated the default*Allocator classes inside of ml-prims! Reason being, I'd like to deprecate the existing DeviceAllocator class inside ml-prims and use defaultDeviceAllocator inside unit-tests of ml-prims. Do you have any concerns with this migration?

Absolutely not. I thought that was the intention of moving the abstract interface of ml-prims.

P.S. FYI: I would like to take a more detailed look on the C++ things you added, but I am not sure if I find time for it this week while I am at GTC. One thought I had after giving this a quick view: I think it would make sense to separate out the basic infrastructure changes from applying it to the pca and tsvd algorithms in different PRs. I understand that you need an algorithm to try this, but I think the review would be more efficient if it is done desperately. Does that make sense to you?

@jirikraus
Copy link
Contributor

unfortunately not. There are parts of tsvd that depend on pca. So, if I change pca that'll affect tsvd too. This PR is looking big because I got carried away with the device-allocator thingy too. Just the cumlHandle changes will probably create a much smaller PR. I'm currently doing the same in my local branch.

Not sure if you got my point. If tsvd depends on pca: Why not use PCA only for the first PR and after that is merged target tsvd. Is there also a depedency of PCA to TSVD? Or perhaps I do not see the reason to have two examples in the initial PR.

@teju85
Copy link
Member Author

teju85 commented Mar 27, 2019

My bad. I actually meant "pca depends on tsvd".

never mind my previous comments. I found a work-around to just confine the changes to PCA alone.

truncCompExpVars(handle, cov.data(), components, explained_var,
explained_var_ratio, prms);
math_t scalar = (prms.n_rows - 1);
Matrix::seqRoot(explained_var, singular_vals, scalar, prms.n_components, true);
Copy link
Contributor

Choose a reason for hiding this comment

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

No stream or handle?

explained_var_ratio, prms);
math_t scalar = (prms.n_rows - 1);
Matrix::seqRoot(explained_var, singular_vals, scalar, prms.n_components, true);
Stats::meanAdd(input, input, mu, prms.n_cols, prms.n_rows, false, true);
Copy link
Contributor

Choose a reason for hiding this comment

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

No stream or handle?

pcaFit(handle, input, components, explained_var, explained_var_ratio, singular_vals,
mu, noise_vars, prms);
pcaTransform(handle, input, components, trans_input, singular_vals, mu, prms);
signFlip(trans_input, prms.n_rows, prms.n_components, components,
Copy link
Contributor

Choose a reason for hiding this comment

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

No stream or handle passed in. I see more instances of this below but will not call them all out.

Stats::sum(total_vars.data(), vars.data(), 1, prms.n_cols, false);

math_t total_vars_h;
updateHost(&total_vars_h, total_vars.data(), 1);
Copy link
Contributor

Choose a reason for hiding this comment

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

synchronous updateHost does not take a stream. This needs to be

updateHostAsync( ..., stream);
cudaStreamSynchronize(stream);

if I do not miss anything.

CUDA_CHECK(cudaGetLastError());

int dev_info;
updateHost(&dev_info, d_dev_info, 1);
updateHost(&dev_info, d_dev_info.data(), 1);
Copy link
Contributor

Choose a reason for hiding this comment

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

To ensure correct stream ordering this needs to be updateHostAsync + cudaStreamSynchronize if I do not miss anything.

@teju85
Copy link
Member Author

teju85 commented Apr 2, 2019

@dantegd the build is failing in CI and that's mostly due to the setup.py changes in this commit are not being picked up during the build!?

@kkraus14
Copy link
Contributor

kkraus14 commented Apr 2, 2019

@dantegd the build is failing in CI and that's mostly due to the setup.py changes in this commit are not being picked up during the build!?

The pip build looks for setup_pip.py instead of setup.py. Both need to be updated.

@teju85
Copy link
Member Author

teju85 commented Apr 3, 2019

Thanks @kkraus14

@teju85
Copy link
Member Author

teju85 commented Apr 7, 2019

Hi all,
Myself and @jirikraus discussed about this PR offline. Here's the summary:

  1. Let Vinay's PR for dbscan+cumlHandle merged first (Introducing cumlHandle API to dbscan and add example #394)
  2. Then get my new PR which only exposes cython-cumlHandle merged ([REVIEW] Exposing cumlhandle in cython #435)
  3. Then create another PR to link the changes in 1 and 2 together
  4. Get the remaining C++ changes I have created in this PR file as a separate one

@dantegd you'll have to (re-)review the python changes once more in PR #435 ! Sorry about the extra-work that this has created for you.

@cjnolet
Copy link
Member

cjnolet commented Apr 16, 2019

Based on this comment:

Get the remaining C++ changes I have created in this PR file as a separate one

@teju85 @jirikraus Can we close this PR?

@jirikraus
Copy link
Contributor

Based on this comment:

Get the remaining C++ changes I have created in this PR file as a separate one

@teju85 @jirikraus Can we close this PR?

@teju85 has the final call, but I think yes this PR is outdated.

@teju85
Copy link
Member Author

teju85 commented Apr 16, 2019

There's only one item pending from my previously commented list above, and that is the corresponding cumlHandle updates for pca and tsvd algos. I have those changes being prepared in pipeline.

Will close this PR, once that is filed. Give me some more time.

@teju85 teju85 changed the title [REVIEW] Expose cumlHandle (+ other goodies!) into cython world [WIP] Expose cumlHandle (+ other goodies!) into cython world Apr 16, 2019
@teju85
Copy link
Member Author

teju85 commented Apr 16, 2019

PR #482 filed for the pca + tsvd related code cleanup and cumlHandle exposure. This PR is no longer needed. Closing.

@teju85 teju85 closed this Apr 16, 2019
@teju85 teju85 deleted the fea-ext-cython-cumlhandle branch April 16, 2019 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 - In Progress Currenty a work in progress Cython / Python Cython or Python issue proposal Change current process or code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants