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

[REVIEW] Port unary to libcudf++ #3214

Merged
merged 47 commits into from
Nov 27, 2019

Conversation

codereport
Copy link
Contributor

@codereport codereport commented Oct 25, 2019

[ISSUE] 2950

Port math_ops.cu
Port unary_ops.cuh


null_ops was done in: 3182
cast_ops was done in: 3397

@codereport codereport requested review from a team as code owners October 25, 2019 06:20
@codereport codereport requested a review from a team October 25, 2019 06:20
@codecov
Copy link

codecov bot commented Oct 25, 2019

Codecov Report

Merging #3214 into branch-0.11 will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff              @@
##           branch-0.11    #3214   +/-   ##
============================================
  Coverage        87.35%   87.35%           
============================================
  Files               49       49           
  Lines             9329     9329           
============================================
  Hits              8149     8149           
  Misses            1180     1180

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1f001ae...d931b0a. Read the comment docs.

[ISSUE] 2950

Port null_ops.cu
@harrism
Copy link
Member

harrism commented Oct 25, 2019

@codereport please avoid force pushes (e.g. use merge rather than rebase) once you have an open PR associated with a feature branch. Github doesn't handle force pushes well. It's most important once people have reviewed the code, because force pushing disassociates comments from the current state of the code.

@codereport
Copy link
Contributor Author

please avoid force pushes

Will avoid these in the future! Thanks!

Copy link
Contributor

@jrhemstad jrhemstad left a comment

Choose a reason for hiding this comment

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

It looks like there was some miscommunication and porting these APIs was already done here: #3182

@harrism
Copy link
Member

harrism commented Oct 26, 2019

@jrhemstad Unary ops encompasses a lot more than just null_ops! But yes, null_ops is a new feature added by @rgsl888prabhu in #2962 and immediately ported to libcudf in #3182. @codereport I don't think you need to touch null_ops, just everything else in unary.hpp

@codereport
Copy link
Contributor Author

@jrhemstad @harrism : @rgsl888prabhu did mention he had code changes for is_null and is_not_null but I though we was just letting me know about the pre-ported changes he merged. Probably could have been avoided if I was notified of the PR numbers (if they aren't already merged that is).

I will focus on the 3 other files.

@harrism
Copy link
Member

harrism commented Oct 27, 2019

null_ops did not exist when I originally created #2950.

@codereport
Copy link
Contributor Author

@harrism Sorry Mark! I wasn't clear - I meant that if Ram had have let me know what the PR #'s were I could have checked. I will just make sure in the future to ask for them :)

@rgsl888prabhu
Copy link
Contributor

I apologize for any inconvenience caused by me.

Remove port of null_ops.cu
It is duplicate work that has been done in 3182
@harrism
Copy link
Member

harrism commented Oct 29, 2019

GitHub has a pretty good PR search function. :)

Copy link
Member

@raydouglass raydouglass left a comment

Choose a reason for hiding this comment

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

Nothing actually for ops to review. Maybe from a merge or force push, but approving to prevent blocking the PR.

@harrism harrism added 2 - In Progress Currently a work in progress libcudf++ labels Oct 29, 2019
@jrhemstad
Copy link
Contributor

@codereport just as a general note, I think the old implementation could be vastly improved by replacing the custom kernel with a thrust::transform.

@codereport
Copy link
Contributor Author

thrust::transform

Thanks @jrhemstad! I will definitely do that

cpp/src/unary/math_ops.cu Outdated Show resolved Hide resolved
cpp/src/unary/math_ops.cu Outdated Show resolved Hide resolved
cpp/src/unary/unary_ops.cuh Outdated Show resolved Hide resolved
cpp/src/unary/unary_ops.cuh Outdated Show resolved Hide resolved
cpp/src/unary/unary_ops.cuh Outdated Show resolved Hide resolved
@codereport
Copy link
Contributor Author

@harrism I am just in the process of adding a couple extra tests, will mark as [REVIEW] once I have added these.

@codereport codereport changed the title [WIP] Port unary to libcudf++ [REVIEW] Port unary to libcudf++ Nov 25, 2019
@codereport codereport added the 3 - Ready for Review Ready for review by team label Nov 25, 2019
@codereport codereport requested a review from trxcllnt November 25, 2019 21:28
Copy link
Member

@harrism harrism left a comment

Choose a reason for hiding this comment

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

Nearly there. Some test suggestions.

CHANGELOG.md Outdated Show resolved Hide resolved
}

template <typename T,
typename std::enable_if_t<std::is_same<T, cudf::experimental::bool8>::value>* = nullptr>
Copy link
Member

Choose a reason for hiding this comment

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

How about factoring out the casting so that all operators can just call a single function rather than maintaining two copies of every operator? Something that calls the actual op with casts only for types that need it, like this. Could be part of a base class that all device_ops inherit.

template<typename T, typename Op, std::enable_if_t<!std::is_same<T, cudf::experimental::bool8>::value>* = nullptr>
__device__ T normalized_unary_op()(Op op, T data) { return Op(data); }

template<typename T, std::enable_if_t<std::is_same<T, cudf::experimental::bool8>::value>* = nullptr>
__device__ T normalized_unary_op()(T data) { return static_cast<T>(Op(static_cast<float>(data)); }

cpp/tests/unary/unary_ops_test.cu Outdated Show resolved Hide resolved
cpp/tests/unary/unary_ops_test.cu Show resolved Hide resolved
cpp/tests/unary/unary_ops_test.cu Show resolved Hide resolved
- update CHANGELOG msg
- refactor math_ops SFINAE to reduce code bloat
- add some "empty" unit tests
- increase test/vector size
cpp/include/cudf/unary.hpp Outdated Show resolved Hide resolved
}

template <typename T,
typename std::enable_if_t<std::is_same<T, cudf::experimental::bool8>::value>* = nullptr>
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs to be resolved in the bool8 type and not externally in functions like this. I'm not sure what the right combinations of implicit/explicit conversion and operators is necessary, but it's not sustainable to have to do things like what was done here in providing two versions of every operator.


if (input.size() == 0) return output;

auto output_view = output->mutable_view();
Copy link
Contributor

Choose a reason for hiding this comment

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

This pattern of passing in the output as a mutable_view prevents any future support of string or other non fixed-width type columns. Granted, most of these unary ops don't make sense on strings. However, I believe these should be modified to return their output rather than pass via a mutable view.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

dispatcher / launcher is updated to return std::unique_ptr<cudf::column_view>

- additional empty column test
- remove stream from public (non-detail) API
- add tests to cover failure cases
@jrhemstad jrhemstad merged commit d206d35 into rapidsai:branch-0.11 Nov 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 - In Progress Currently a work in progress 3 - Ready for Review Ready for review by team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants