DOC minor broken links fix in parallelism docs
@@ -114,9 +114,11 @@ threads than the number of CPUs on a machine. Over-subscription happens when
a program is running too many threads at the same time.
Suppose you have a machine with 8 CPUs. Consider a case where you're running
-a :class:`~GridSearchCV` (parallelized with joblib) with ``n_jobs=8`` over
-a :class:`~HistGradientBoostingClassifier` (parallelized with OpenMP). Each
-instance of :class:`~HistGradientBoostingClassifier` will spawn 8 threads
+a :class:`~sklearn.model_selection.GridSearchCV` (parallelized with joblib)
+with ``n_jobs=8`` over a
+:class:`~sklearn.ensemble.HistGradientBoostingClassifier` (parallelized with
+OpenMP). Each instance of
+:class:`~sklearn.ensemble.HistGradientBoostingClassifier` will spawn 8 threads
(since you have 8 CPUs). That's a total of ``8 * 8 = 64`` threads, which
leads to oversubscription of physical CPU resources and to scheduling
overhead.
@@ -129,9 +131,10 @@ is the default), joblib will tell its child **processes** to limit the
number of threads they can use, so as to avoid oversubscription. In practice
the heuristic that joblib uses is to tell the processes to use ``max_threads
= n_cpus // n_jobs``, via their corresponding environment variable. Back to
-our example from above, since the joblib backend of :class:`~GridSearchCV`
-is ``loky``, each process will only be able to use 1 thread instead of 8,
-thus mitigating the oversubscription issue.
+our example from above, since the joblib backend of
+:class:`~sklearn.model_selection.GridSearchCV` is ``loky``, each process will
+only be able to use 1 thread instead of 8, thus mitigating the
+oversubscription issue.
Note that:
