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

Handle multibyte_split byte_range out-of-bounds offsets on host #11885

Merged

Conversation

upsj
Copy link
Contributor

@upsj upsj commented Oct 10, 2022

Description

In order to uniformize the interface for a future combined handling of byte ranges between read_csv and read_text, this PR replaces the cutoff_offset by a plain integer again, and handles finding the first out-of-bounds on the host side instead.

Checklist

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

@upsj upsj added 3 - Ready for Review Ready for review by team libcudf Affects libcudf (C++/CUDA) code. tech debt improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels Oct 10, 2022
@upsj upsj self-assigned this Oct 10, 2022
@upsj upsj requested a review from a team as a code owner October 10, 2022 14:39
@upsj upsj requested review from vyasr and hyperbolic2346 October 10, 2022 14:39
@codecov
Copy link

codecov bot commented Oct 10, 2022

Codecov Report

Base: 87.40% // Head: 88.11% // Increases project coverage by +0.70% 🎉

Coverage data is based on head (a4dabe4) compared to base (f72c4ce).
Patch coverage: 85.47% of modified lines in pull request are covered.

Additional details and impacted files
@@               Coverage Diff                @@
##           branch-22.12   #11885      +/-   ##
================================================
+ Coverage         87.40%   88.11%   +0.70%     
================================================
  Files               133      133              
  Lines             21833    21881      +48     
================================================
+ Hits              19084    19281     +197     
+ Misses             2749     2600     -149     
Impacted Files Coverage Δ
python/cudf/cudf/core/udf/__init__.py 97.05% <ø> (+47.05%) ⬆️
...thon/dask_cudf/dask_cudf/tests/test_distributed.py 18.86% <ø> (+4.94%) ⬆️
python/cudf/cudf/core/_base_index.py 82.20% <43.75%> (-3.35%) ⬇️
python/cudf/cudf/io/text.py 91.66% <66.66%> (-8.34%) ⬇️
python/strings_udf/strings_udf/__init__.py 86.27% <76.00%> (-10.61%) ⬇️
python/cudf/cudf/core/index.py 92.91% <98.24%> (+0.28%) ⬆️
python/cudf/cudf/__init__.py 90.69% <100.00%> (ø)
python/cudf/cudf/core/column/categorical.py 89.34% <100.00%> (ø)
python/cudf/cudf/core/scalar.py 90.52% <100.00%> (+1.25%) ⬆️
python/cudf/cudf/utils/ioutils.py 79.47% <100.00%> (ø)
... and 13 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

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.

Unsure how I feel about changing something well defined like cutoff_offset for int64_t. I wonder if we shouldn't change it to a using like using cutoff_offset_type = int64_t.

cpp/src/io/text/multibyte_split.cu Outdated Show resolved Hide resolved
cpp/src/io/text/multibyte_split.cu Show resolved Hide resolved
cpp/src/io/text/multibyte_split.cu Outdated Show resolved Hide resolved
@upsj
Copy link
Contributor Author

upsj commented Oct 12, 2022

@hyperbolic2346 To give some context, I only introduced the cutoff_offset to handle byte ranges on the device side, but that turned out to be a little problematic to generalize for other parsers. In this PR, the offsets (which are offsets into the offset array, not offsets into the string) are no longer being cut off after the byte range, so I didn't want to use that name any more.

@hyperbolic2346
Copy link
Contributor

In this PR, the offsets (which are offsets into the offset array, not offsets into the string) are no longer being cut off after the byte range, so I didn't want to use that name any more.

I can understand that. My concern comes from how easy it is to notice a lack of offset_thing vs int32_t not matching the type. I'm not against this change or using int64_t for it. I simply worry about bugs introduced later because there isn't a name for this thing.

@upsj
Copy link
Contributor Author

upsj commented Oct 12, 2022

Do you have a suggestion for a suitable name? I used the tongue-in-cheek name offset_offset for a while, but that doesn't really explain its purpose. Maybe output_offset, as it's an offset into the output array?

@hyperbolic2346
Copy link
Contributor

Do you have a suggestion for a suitable name? I used the tongue-in-cheek name offset_offset for a while, but that doesn't really explain its purpose. Maybe output_offset, as it's an offset into the output array?

Everything I think of is either in use or isn't fitting. Offset of some sort. output_offset seems reasonable and matches most of the variables using it as well.

@upsj upsj requested a review from hyperbolic2346 October 13, 2022 16:43
@upsj upsj added 4 - Needs cuIO Reviewer 3 - Ready for Review Ready for review by team and removed 3 - Ready for Review Ready for review by team labels Oct 13, 2022
Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

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

A couple small suggestions, otherwise LGTM.

cpp/src/io/text/multibyte_split.cu Outdated Show resolved Hide resolved
cpp/src/io/text/multibyte_split.cu Outdated Show resolved Hide resolved
Co-authored-by: Bradley Dice <[email protected]>
Comment on lines +167 to +168
using output_offset = int64_t;
using byte_offset = int64_t;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this? If you want to completely differentiate between these types, simple type aliasing like this is not enough. Instead, strong types should be prefered:

enum class output_offset : int64_t {};
enum class byte_offset : int64_t {};

Using strong types may be more difficult to do arithmetic operations but you can always cast the values to int64_t when doing so.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this approach has its shortcomings, I mainly wanted to make clear what different offsets point to, more avoiding raw integer types for readability than true type safety. I need to to enough arithmetic on the types that using an enum class would be really inconvenient. Something like BOOST_STRONG_TYPEDEF would probably fit.

Copy link
Contributor

Choose a reason for hiding this comment

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

Both approaches have pros and cons. For this case, I think a simple using is sufficient, with a weakly aliased type. It does pose some benefit to readability, and the need for arithmetic operators makes it difficult to use a strong type like an enum class. I'm happy with the tradeoffs that @upsj took in this case.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also: @ttnghia we need strong types for the left/right comparator indices (the last time I remember discussing this topic) to ensure that function signatures match the given types. That isn't as much of a concern here because the weakly aliased types here aren't being passed to functions with multiple overloads for plain integers and strong types.

@upsj upsj added the 5 - Ready to Merge Testing and reviews complete, ready to merge label Oct 15, 2022
@upsj
Copy link
Contributor Author

upsj commented Oct 15, 2022

@gpucibot merge

@rapids-bot rapids-bot bot merged commit 9f8b936 into rapidsai:branch-22.12 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5 - Ready to Merge Testing and reviews complete, ready to merge improvement Improvement / enhancement to an existing function libcudf Affects libcudf (C++/CUDA) code. non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants