Optimize dtype conversion for FIL #4070
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dantegd
added
improvement
|
nice! much better than current state |
|
Thanks for looking into this! Thinking further: I think the conversion (implemented on the GPU) can be fast even with the accuracy check enabled. |
wphicks
approved these changes
Jul 28, 2021
dantegd
changed the title
Co-authored-by: William Hicks <wphicks@users.noreply.github.com>
dantegd
changed the title
|
rerun tests |
|
@gpucibot merge |
Codecov Report
@@ Coverage Diff @@
## branch-21.08 #4070 +/- ##
===============================================
Coverage ? 85.83%
===============================================
Files ? 231
Lines ? 18272
Branches ? 0
===============================================
Hits ? 15684
Misses ? 2588
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
vimarsh6739
pushed a commit
to vimarsh6739/cuml
that referenced
this pull request
Oct 9, 2023
cc @canonizer @levsnv @wphicks After doing a little bit of profiling for the slowness we observed for FIL when data had to be converted from int16 to float32 I found out that ~98% of the time was being spent in the check of whether there would be information lost to under/overflows in https://github.com/rapidsai/cuml/blob/c3c4376ab8a3af3e0c92aa2c9ae5d8b8fe116b8c/python/cuml/common/input_utils.py#L590 Created this proposal PR to add a parameter to skip that check in methods that are fast enough to benefit from fast dtype conversion like FIL as well as skip the check when upcasting. In my first quick benchmarks the dtype conversion was between **4x~14x** faster when disabling the checks in some cases. PR is still in progress, but figured I'd ping you in case you wanted to take a look Authors: - Dante Gama Dessavre (https://github.com/dantegd) Approvers: - William Hicks (https://github.com/wphicks) - Corey J. Nolet (https://github.com/cjnolet) URL: rapidsai#4070
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc @canonizer @levsnv @wphicks
After doing a little bit of profiling for the slowness we observed for FIL when data had to be converted from int16 to float32 I found out that ~98% of the time was being spent in the check of whether there would be information lost to under/overflows in
cuml/python/cuml/common/input_utils.py
Line 590 in 3c11ebd
Created this proposal PR to add a parameter to skip that check in methods that are fast enough to benefit from fast dtype conversion like FIL as well as skip the check when upcasting.
In my first quick benchmarks the dtype conversion was between 4x~14x faster when disabling the checks in some cases. PR is still in progress, but figured I'd ping you in case you wanted to take a look