From #20651 (reply in thread), two small optimizations could improve the scalability when using threads:

• avoiding the redundant check_random_state in BaseDecisionTree.fit as it's already initialized by the forest when bootstrap to data for the tree specifically.
• avoiding the assert_all_finite in _check_sample_weight in BaseDecisionTree.fit.

For reference, here is the extract of the sequential execution profiling:

I think threading is still the most appropriate backend by default. In #20651 the individual trees are very fast to train (4ms) and many trees are fitted (1000) which is not representative of the typical use case.

If the tree fitting time lasted 1s or more, then the GIL-holding segments of the code would be negligible and the thread-based scalability would be fine.

not representative

I agree, it's dataset dependent. Switch out load_boston for fetch_california in my example to get a larger training set, and I see the expected speedup cross-platform.

hey @ogrisel @brianbien , could you please help me resolving this issue? I would like to contribute to it

@Bhavay192 Feel free to have a look at the code of the random forests and the decision trees to try to open a PR to solve one item of #20666 (comment) at a time to keep the PR focused.

Feel free to ask specific questions on gitter if you need more help: https://gitter.im/scikit-learn/scikit-learn

Before opening a PR for this issue, we should reevaluate with a free-threading build of scikit-learn on CPython 3.13.

Here are some resources to get started: https://py-free-threading.github.io/

Scikit-learn's CI also automatically publishes nightly wheels for cp313t as numpy and scipy (along with the other nightly wheels):

https://scikit-learn.org/stable/developers/advanced_installation.html#installing-nightly-builds