[Rust] [Experiment] Trigonometry kernels

[nevi-me]

This is on top of #9297

I was curious if (ab)using the compute::unary kernel 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:

• arithmetics with scalars
• functions that would otherwise require generating intermediate arrays (e.g. sin(x) * cos(x) would be multiply(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

cargo bench --bench trigonometry_kernels
cargo bench --bench trigonometry_kernels --features simd
RUSTFLAGS="-C target-cpu=native" cargo bench --bench trigonometry_kernels
RUSTFLAGS="-C target-cpu=native" cargo bench --bench trigonometry_kernels --features simd

haversine_no_unary 512 time:[14.074 us 14.140 us 14.216 us]
haversine_unary 512 time:[11.191 us 11.308 us 11.436 us]
haversine_no_unary_nulls 512 time:[15.902 us 15.985 us 16.083 us]
haversine_unary_nulls 512 time:[12.486 us 12.552 us 12.625 us]

The biggest benefit is from setting the RUSTFLAGS, the non-null benches go 3-10% faster.

[github-actions]

Thanks for opening a pull request!

Could you open an issue for this pull request on JIRA?
https://issues.apache.org/jira/browse/ARROW

Then could you also rename pull request title in the following format?

ARROW-${JIRA_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - How to contribute patches

[nevi-me]

@jorgecarleitao I had to convert the floats to T::Native in order to use them in the unary kernel as part of Fn(_) expressions.

[jorgecarleitao]

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.

[jorgecarleitao]

IMO looked good to me (before the rebase), however, a more through review would need a rebase xD

[nevi-me]

I've rebased.

Ideas for the PR before I work more on it:

• Are the trig kernels fine (is the direction good)?
• Should I remove Haversine? I was using it to evaluate the performance benefit of using unary

[codecov-io]

Codecov Report

Merging #9313 (ef36a3d) into master (53d392c) will increase coverage by 0.00%.
The diff coverage is 87.01%.

@@ 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 

Impacted Files	Coverage Δ
rust/arrow/src/compute/kernels/trigonometry.rs	86.48% <86.48%> (ø)
rust/arrow/src/compute/kernels/arity.rs	92.85% <100.00%> (+1.19%)	⬆️

---

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 53d392c...ef36a3d. Read the comment docs.

[jorgecarleitao]

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.

[jorgecarleitao]

shouldn't we move this to the tests, if it is only used for testing?

[nevi-me]

I've removed it, as it's also in the benchmark

[jorgecarleitao]

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.

[nevi-me]

Thanks @jorgecarleitao, I'm currently constrained with time during the week. I'll finish this up over the weekend

[alamb]

@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