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

New Decimal <--> Floating conversion #15905

Merged

Conversation

pmattione-nvidia
Copy link
Contributor

@pmattione-nvidia pmattione-nvidia commented Jun 2, 2024

This PR contains the main algorithm for the new decimal <--> floating conversion code. This algorithm was written to address the precision issues described here.

Summary

  • The new algorithm is more accurate than the previous code, but it is also far more complex.
  • It can perform conversions that were not even possible in the old code due to overflow (decimal32/64/128 conversions only worked for scale factors up to 10^9/18/38, respectively). Now the entire floating-point range is convertible, including denormals.
  • This new algorithm is significantly faster in some parts of the conversion phase-space, and in some parts slightly slower.

Previous PR's

These contain the supporting parts of this work:

Algorithm Outline

We convert floating -> (integer) decimal by:

  • Extract the floating-point mantissa (converted to integer) and power-of-2
  • For float we use a uint64 to contain our data during the below shifting/scaling, for double uint128_t
  • In this shifting integer, we alternately apply the extracted powers-of-2 (bit-shifts, until they're all used) and scale-factor powers-of-10 (multiply/divide) as needed to reach the desired scale factor.

Decimal -> floating is just the reverse operation.

Supplemental Changes

  • Testing: Add decimal128, add precise-conversion tests. Remove kludges due to inaccurate conversions. Add test for zeroes.
  • Benchmarking: Enable regions of conversion phase-space for benchmarking that were not possible in the old algorithm.
  • Unary: Cleanup by using CUDF_ENABLE_IF. Call new conversion code for base-10 fixed-point.

Performance for various conversions/input-ranges

  • Note: F32/F64 is float/double

New algorithm is FASTER by:

  • F64 --> decimal64: 60% for E8 --> E15
  • F64 --> decimal128: 13% for E-8 --> E-15
  • F64 --> decimal128: 22% for E8 --> E15
  • F64 --> decimal128: 27% for E31 --> E38
  • decimal32 --> F64: 18% for E-3 --> E4
  • decimal64 --> F64: 27% for E-14 --> E-7
  • decimal64 --> F64: 17% for E-3 --> E4
  • decimal128 --> F64: 21% for E-14 --> E-7
  • decimal128 --> F64: 11% for E-3 --> E4
  • decimal128 --> F64: 13% for E31 --> E38

New algorithm is SLOWER by:

  • F32 --> decimal32: 3% for E-3 --> E4
  • F32 --> decimal64: 2% for E-14 --> E14
  • F64 --> decimal32: 3% for E-3 --> E4
  • decimal32 --> F32: 5% for E-3 --> E4
  • decimal128 --> F64: 36% for E-37 --> E-30

Other kernels:

  • The PYMOD binary-op benchmark is 7% slower.

Performance discussion

  • Many conversions have identical speed, indicating these algorithms are often fast and we are instead bottlenecked on overheads such as getting the input to the gpu in the first place.
  • F64 conversions are often much faster than the old algorithm as the new algorithm completely avoids the FP64 pipeline. Other than the cast to double itself, all of the operations are on integers. Thus we don't have threads competing with each other and taking turns for access to the floating-point cores.
  • The conversions are slightly slower for floats with powers-of-10 near zero. Presumably this is due to code overhead for e.g., handling a large range of inputs, UB-checks for bit shifts, branches for denormals, etc.
  • The conversion is slower for decimal128 conversions with very small exponents, which requires several large divisions (128bit divided by 64bit).
  • The PYMOD kernel is slower due to register pressure from the introduction of the new division routines in the earlier PR. Even though this benchmark does not perform decimal <--> floating conversions, it gets hit because of inlined template code in the kernel increasing the code/register pressure.

Checklist

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.

@pmattione-nvidia pmattione-nvidia added libcudf Affects libcudf (C++/CUDA) code. Performance Performance related issue improvement Improvement / enhancement to an existing function labels Jun 2, 2024
@pmattione-nvidia pmattione-nvidia self-assigned this Jun 2, 2024
@pmattione-nvidia pmattione-nvidia added the non-breaking Non-breaking change label Jun 2, 2024
@pmattione-nvidia pmattione-nvidia marked this pull request as ready for review June 2, 2024 23:22
@pmattione-nvidia pmattione-nvidia requested a review from a team as a code owner June 2, 2024 23:22
@pmattione-nvidia pmattione-nvidia requested review from vyasr and ttnghia June 2, 2024 23:22
@pmattione-nvidia
Copy link
Contributor Author

pmattione-nvidia commented Jun 3, 2024

NOTE: Nevermind, the below is now working, the algorithm was tweaked accordingly.

Note that currently the python tests are failing because of 97938.2f -> decimal64 with scale-factor -2. Note that the tests this was failing on before (in the original linked issue) now pass (higher levels of precision), this failure is different. This failure due to the increment_on_truncation() function, where we increment when we should not. Specifically we are triggering the "// The only way that this produces the incorrect result is if ..." condition.

I could change the xfail in the python test to fail this case instead of the others, but I'm trying to see if I can think of a solution ... I'm betting arrow is able to figure it out BECAUSE of this precision argument (7 decimal digits, which is the max precision of float) which we don't have ... perhaps we should have this as an optional argument?

@pmattione-nvidia pmattione-nvidia requested a review from a team as a code owner June 3, 2024 13:44
@pmattione-nvidia pmattione-nvidia requested a review from Matt711 June 3, 2024 13:44
@github-actions github-actions bot added the Python Affects Python cuDF API. label Jun 3, 2024
Copy link
Contributor

@wence- wence- left a comment

Choose a reason for hiding this comment

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

Some comments on the comments

cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/tests/fixed_point/fixed_point_tests.cpp Show resolved Hide resolved
@pmattione-nvidia pmattione-nvidia requested a review from a team as a code owner June 27, 2024 18:52
@github-actions github-actions bot added the Java Affects Java cuDF API. label Jun 27, 2024
Copy link
Member

@jlowe jlowe left a comment

Choose a reason for hiding this comment

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

Java approval

cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/fixed_point/floating_conversion.hpp Outdated Show resolved Hide resolved
cpp/include/cudf/unary.hpp Show resolved Hide resolved
cpp/include/cudf/unary.hpp Show resolved Hide resolved
@@ -34,6 +35,49 @@ namespace numeric {

namespace detail {
Copy link
Contributor

Choose a reason for hiding this comment

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

The entire source of this file is in the detail namespace but the file is in a public header directory.
Are these meant to be called only internally then? We are evaluating public/internal functions/source recently.
Perhaps this could be moved to detail directory instead -- cudf/fixed_point/detail would probably be ok.

Now I'm seeing this is called from public unary.hpp which has its own issue.
So this is probably out of scope for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there an issue for this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some of this functionality needs to be exposed for the spark-rapids-jni repository to wrap around for it to perform conversions with the spark-specific rounding. I'm still finalizing the details for the sr-jni code, when that's done I'll have a better idea of what the minimal amount of code we can expose is.

cpp/tests/fixed_point/fixed_point_tests.cpp Show resolved Hide resolved
@pmattione-nvidia
Copy link
Contributor Author

Note that cuDF necessarily will NOT match pyarrow, due to choosing to truncate where pyarrow wants to round.

Copy link
Contributor

@hyperbolic2346 hyperbolic2346 left a comment

Choose a reason for hiding this comment

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

The comments in this code are really good. I appreciate the time spent adding them to explain the dense conversions going on in here.

@@ -34,6 +35,49 @@ namespace numeric {

namespace detail {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there an issue for this change?

@pmattione-nvidia
Copy link
Contributor Author

/merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement / enhancement to an existing function Java Affects Java cuDF API. libcudf Affects libcudf (C++/CUDA) code. non-breaking Non-breaking change Performance Performance related issue Python Affects Python cuDF API.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants