-
Notifications
You must be signed in to change notification settings - Fork 4k
[Rust] [Experiment] Trigonometry kernels #9313
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
Conversation
|
Thanks for opening a pull request! Could you open an issue for this pull request on JIRA? Then could you also rename pull request title in the following format? See also: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jorgecarleitao I had to convert the floats to T::Native in order to use them in the unary kernel as part of Fn(_) expressions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not find any easy way of doing this, also. It feels like we would need a generic of a generic. It looks good to me, though.
|
IMO looked good to me (before the rebase), however, a more through review would need a rebase xD |
d19ae1d to
ef36a3d
Compare
|
I've rebased. Ideas for the PR before I work more on it:
|
Codecov Report
@@ Coverage Diff @@
## master #9313 +/- ##
=======================================
Coverage 81.90% 81.91%
=======================================
Files 216 217 +1
Lines 52990 53066 +76
=======================================
+ Hits 43402 43468 +66
- Misses 9588 9598 +10
Continue to review full report at Codecov.
|
jorgecarleitao
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if this is ready to review, as it is marked as draft, but I reviewed it anyways.
LGTM, thanks a lot for taking this! :)
I left some ideas / suggestions but I am fine as is also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we move this to the tests, if it is only used for testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed it, as it's also in the benchmark
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would try to get the result from the exercise, drop this code once the best option was found, and document which was was better in implementation notes on the decided approach.
|
Thanks @jorgecarleitao, I'm currently constrained with time during the week. I'll finish this up over the weekend |
ef36a3d to
7423452
Compare
7423452 to
694e05d
Compare
d4608a9 to
356c300
Compare
|
@nevi-me I am closing this PR for the time being to clean up the Rust/Arrow PR backlog. Please let me know if this is a mistake |
This is on top of #9297
I was curious if (ab)using the
compute::unarykernel would perform better on slightly complex functions.I implemented the Haversine function, which calculates the distance between two geographic coordinates.
I then benchmarked an implementation that I tried to simplify and optimise with unary kernels, vs one that I'd have to write if I couldn't use the unary kernels for things like:
sin(x) * cos(x)would bemultiply(sin(x), cos(x)))The function that uses unary kernels for the above, is slightly faster.
I ran this on an M1 CPU, with the below options
The biggest benefit is from setting the
RUSTFLAGS, the non-null benches go 3-10% faster.