tustvold opened a new issue, #2647:
URL: https://github.com/apache/arrow-rs/issues/2647

   **Which part is this question about**
   <!--
   Is it code base, library api, documentation or some other part?
   -->
   
   In Rust division and modulus is **always checked** - you can see that 
[here](https://rust.godbolt.org/z/eKn5Yzdnc). We currently provide checked and 
unchecked division kernels, and a single modulus kernel which is always checked.
   
   The result is that the checked kernels will return an error on divide by 
zero, whilst the unchecked kernel will panic. This feels a little 
counter-intuitive, I would expect the unchecked kernel to silently do 
"something defined but not necessarily meaningful".
   
   **Describe your question**
   <!--
   A clear and concise description of what the question is.
   -->
   
   The comparison kernels handle the null mask separately from the values data, 
and this massively improves performance. I would like to apply the same 
optimisation to the unchecked arithmetic kernels, but cannot do this whilst 
dividing or modulus by 0 results in a panic, as the null values may have 
arbitrary values which could trigger this.
   
   I would like to propose the unchecked variant of these division kernels set 
the value to be 0 on division by 0 (or some other sentinel value). As we're 
checking regardless there is no performance impact of doing this, and it allows 
blindly processing the values without first consulting the bitmask.
   
   An alternative option would be to only have checked variants, however, this 
would preclude handling the null mask separately for the non-scalar variants of 
the kernels. I think this would be a shame.
   
   One further alternative I did consider was to only consult the bitmask on 
divide by zero, however, the reality is most null slots will have a value of 0, 
and consequently this cost of this conditional checking is likely to undermine 
any benefits from the optimisation.
   
   **Additional context**
   <!--
   Add any other context about the problem here.
   -->
   
   Thoughts @alamb @viirya @Dandandan @jhorstmann ?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to