Thanks to visit codestin.com
Credit goes to github.com

Skip to content

PRF Mitigation of poor scalability of HGB - #34912

Draft
cakedev0 wants to merge 30 commits into
scikit-learn:mainfrom
cakedev0:hgb/only_uniformly_positive_heuristics
Draft

PRF Mitigation of poor scalability of HGB#34912
cakedev0 wants to merge 30 commits into
scikit-learn:mainfrom
cakedev0:hgb/only_uniformly_positive_heuristics

Conversation

@cakedev0

@cakedev0 cakedev0 commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

WIP: still cleaning the diff, fixing tests, ...

Finally, I have something that has a uniformly positive impact on the 8 scenarios I'm testing:

  • Big machine with default OMP settings
  • Big machine with default OMP_PROC_BIND=close => this setting is somewhat representative of [TODO]
  • Laptop with no active wait enabled (behavior of conda-forge packages)
  • Laptop with active wait

(x Libgomp & libomp for each of those cases)

Reference Issues/PRs

Implements item 4 partially, and item 5 of #34764 (comment)

And I'd say it also closes #14306. Though this issues does have some interesting idea that are not implemented here, especially parallelism over block of samples x features for the histogram building. Still, benchmarks show HGB does continue to scale until 16-32 threads for many medium/big datasets (as long as active wait is enabled). I personally would consider that good enough ^^

What does this implement/fix? Explain your changes.

  • Limit number of threads for tree-growth based on number of features and some heuristics
  • Use a serialized implementation of apply split when the number of samples is small compared to the number of threads => this makes apply split scales as well as it can (scale when possible, do not regress otherwise)
  • Some limitations on the number of threads for the binning

AI usage disclosure: mostly not

Benchmarks

probabl-ai/scikit-learn-benchmarks#74

Except one case regressing on the GNR that is probably due to numa placement (see probabl-ai/scikit-learn-benchmarks#80), no regression further than ~5% and some very neat improvements (especially on the GNR).

You'll see the no-active-wait set-ups still scale very counter-productively in many cases, I plan to try tackling that in a follow-up PR. Current plan:

  • detect active wait, either by reading some logs (a bit slow), or by probing.
  • maybe? for libomp, use set_kmp_block_time to actually enable active wait (maybe dangerous if inside outer parallelism)
  • then adapt heuristics and/or warn users about what they should do (maybe link to documentation?)

For the scalability on machines like the GNR, it's still not perfect but I don't think it's worth improving more than that.

"HistGradientBoosting",
[HistGradientBoostingClassifier, HistGradientBoostingRegressor],
)
def test_max_features_less_than_one_does_not_crash(HistGradientBoosting):

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

TODO: remove

@cakedev0

Copy link
Copy Markdown
Contributor Author

Closed in favor of #34935

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multicore scalability of the Histogram-based GBDT

1 participant