MNT Refactor/Improve features sampling in HGB splitting - #34786
Open
cakedev0 wants to merge 2 commits into
Open
Conversation
ogrisel
approved these changes
Sep 10, 2026
ogrisel
left a comment
Member
There was a problem hiding this comment.
LGTM. I agree that it's having parallel loops with more homogeneous workloads should help optimize the thread-scalability in subsequent PRs.
Another benefit: I find the code easier to reason about this way.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Reference Issues/PRs
Will help in implementing strategy 4 described in #34764 (comment)
What does this implement/fix? Explain your changes.
It changes the features subsampling of HGB (when
max_features < 1.0): instead of a boolean mask, it samples without replacement.It has two benefits:
prange(..., schedule="static"), which will help for future scalability heuristic I'm working onmax_features < 1.0), as it randomized the order in which features are split (and we use > in the loop).The effect on runtime is not visible as far as I could experiment, even in extreme cases where split time is dominant. But I think it should be visible in some (relatively rare) cases once combine with the "use_threads_if" heuristic as it allow having a more accurate estimate of the work to do.
There is no added complexity so it's worth the PR/merge I'd say.
AI usage disclosure
Very guided session, I had a precise idea of what I wanted.