Exposes thread_count for Catboost estimators as n_jobs parameters and n_jobs as a keyword argument for XGBoost

[angela97lin]

Closes #1475.

Some UX questions and concerns:

• What happens if user specifies thread_count and n_jobs? Currently, will only use the n_jobs parameter. That means if a user sets thread_count to 2, but does not set n_jobs which defaults to -1, we will still use -1. I think this is okay given that our API specifies n_jobs as the parameter to use for multicore processing, but this could be a bit confusing (especially given XGBoost/CatBoost use threads, scikit-learn uses processes).

---

Image after exposing n_jobs for CatBoost:

XGBoost: Since we use the python scikit-learn interface, n_jobs is already implemented. This PR just exposes n_jobs as a named argument :)

---

It's interesting to note that XGBoost takes more time using all threads than with just two. There is some documentation about how thread contention slows down the algorithm which probably plays a role in this. See image below for how the runtime slows down after setting >16 threads. I filed #2437 to further track this, as it could be useful to investigate this with more datasets and runs.

Relevant links: https://xgboost.readthedocs.io/en/latest/python/python_api.html#module-xgboost.core; dmlc/xgboost#3810

[codecov]

Codecov Report

Merging #2410 (30ba35d) into main (ef06526) will increase coverage by 0.1%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main   #2410     +/-   ##
=======================================
+ Coverage   99.6%   99.7%   +0.1%     
=======================================
  Files        283     283             
  Lines      25486   25539     +53     
=======================================
+ Hits       25384   25437     +53     
  Misses       102     102             

Impacted Files	Coverage Δ
...nents/estimators/classifiers/xgboost_classifier.py	100.0% <ø> (ø)
evalml/tests/component_tests/test_components.py	100.0% <ø> (ø)
...ents/estimators/classifiers/catboost_classifier.py	100.0% <100.0%> (ø)
...onents/estimators/regressors/catboost_regressor.py	100.0% <100.0%> (ø)
...ponents/estimators/regressors/xgboost_regressor.py	100.0% <100.0%> (ø)
...lml/tests/automl_tests/test_iterative_algorithm.py	100.0% <100.0%> (ø)
.../tests/component_tests/test_catboost_classifier.py	100.0% <100.0%> (ø)
...l/tests/component_tests/test_catboost_regressor.py	100.0% <100.0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef06526...30ba35d. Read the comment docs.

[jeremyliweishih]

I think this looks good! RE your UX question I think its fine the way it is but maybe we can add an explanation in the docstring of the catboost components for clarity.

[freddyaboulton]

@angela97lin I think this looks great! I have two points I'd like to resolve before merging:

1. Can you add coverage to the AutoMLSearch/IterativeAlgorithm that xgboost and catboost are initialized with the right value of n_jobs? I don't think this line was working as intended for those estimators before this pr right? https://github.com/alteryx/evalml/blob/main/evalml/automl/automl_algorithm/iterative_algorithm.py#L258

2. Since we'll now be running xgboost with n_jobs=-1 by default and you noted that can slow down xgboost, how much slower will AutoMLSearch after this PR? Might be good to quantify that via perf tests so we can tag #2437 as high priority.

Let me know what you think!

[bchen1116]

LGTM! Nice tests and documentation!

[bchen1116]

nice catch!

[chukarsten]

Looks good to me!