XGBoost 和交叉验证并行
XGBoost and cross-validation in parallel
我看到 XGBClassifier() 和 sklearn.model_selection.RandomizedSearchCV() 都有参数 n_jobs。我执行了 CV，我看到通过设置 n_jobs = -1（在两者中）我利用了我拥有的 16 个工人：
Fitting 5 folds for each of 30 candidates, totalling 150 fits
[Parallel(n_jobs=-1)]: Using backend LokyBackend with 16 concurrent workers.
[Parallel(n_jobs=-1)]: Done 9 tasks | elapsed: 13.7min
[Parallel(n_jobs=-1)]: Done 18 tasks | elapsed: 20.4min
[Parallel(n_jobs=-1)]: Done 29 tasks | elapsed: 23.7min
[Parallel(n_jobs=-1)]: Done 40 tasks | elapsed: 28.7min
[Parallel(n_jobs=-1)]: Done 53 tasks | elapsed: 36.1min
[Parallel(n_jobs=-1)]: Done 66 tasks | elapsed: 43.4min
[Parallel(n_jobs=-1)]: Done 81 tasks | elapsed: 47.6min
[Parallel(n_jobs=-1)]: Done 96 tasks | elapsed: 50.8min
[Parallel(n_jobs=-1)]: Done 113 tasks | elapsed: 60.0min
[Parallel(n_jobs=-1)]: Done 135 out of 150 | elapsed: 73.1min remaining: 8.1min
[Parallel(n_jobs=-1)]: Done 150 out of 150 | elapsed: 85.7min finished
我现在无法重复分析，但我假设并行化是由于 RandomizedSearchCV() 中的 n_jobs=1 而发生的。
我对并行计算知之甚少。我知道 RandomizedSearchCV() 独立运行每个参数设置，但它在并行化时具体如何工作？那么 n_jobs=-1 和 XGBClassifier() 呢？在两个函数中都设置这个参数有意义吗？
Q: Does it make sense to set this parameter in both functions?
一个简短的版本：不，它没有。
较长的版本需要了解一下 n_jobs 的实际处理方式。
有一些昂贵的资源（对，CPU-cores 本身，最快和最昂贵的 CPU-core-local 缓存层次结构元素（不会深入研究 cache-lines以及它们在这个级别各自的关联性）和更便宜但也更慢的 RAM-memory ）， n_jobs = -1 指令，在第一个 call-signature 执行, 将立即获取所有这些资源。
这意味着，将没有合理的 "free" 资源用于任何 "deeper" 级别的尝试使用 -再次- "as many resources" 物理可用（ n_jobs = -1 再次执行并遵守，但是没有 "free" 从第一个中脱颖而出，在极其 "over-subscribed"（超载队列很少有实际（因此在任何不久的将来都不会免费）资源来利用的任务）O/S 的并发性 task-scheduler 的调度尝试映射/逐出/映射/逐出/映射/逐出因此在相同的真实（并且已经很忙）硬件元素上有更多的处理工作。
通常即使是第一次尝试也可能会在 RAM-allocations 方面造成麻烦，因为大型模型在过程实例化期间需要在所有 RAM-data-structures 中进行多次复制（整个副本有效地制作了所有对象，使用或未使用，复制到每个新进程中），作为 CPU-cores "dictates" 的数量。由此产生的内存交换绝对是您永远不会喜欢重复的事情。
享受模型 HyperParameters 的调整 - 它是机器学习实践的精华。值得擅长
我看到 XGBClassifier() 和 sklearn.model_selection.RandomizedSearchCV() 都有参数 n_jobs。我执行了 CV，我看到通过设置 n_jobs = -1（在两者中）我利用了我拥有的 16 个工人：
Fitting 5 folds for each of 30 candidates, totalling 150 fits
[Parallel(n_jobs=-1)]: Using backend LokyBackend with 16 concurrent workers.
[Parallel(n_jobs=-1)]: Done 9 tasks | elapsed: 13.7min
[Parallel(n_jobs=-1)]: Done 18 tasks | elapsed: 20.4min
[Parallel(n_jobs=-1)]: Done 29 tasks | elapsed: 23.7min
[Parallel(n_jobs=-1)]: Done 40 tasks | elapsed: 28.7min
[Parallel(n_jobs=-1)]: Done 53 tasks | elapsed: 36.1min
[Parallel(n_jobs=-1)]: Done 66 tasks | elapsed: 43.4min
[Parallel(n_jobs=-1)]: Done 81 tasks | elapsed: 47.6min
[Parallel(n_jobs=-1)]: Done 96 tasks | elapsed: 50.8min
[Parallel(n_jobs=-1)]: Done 113 tasks | elapsed: 60.0min
[Parallel(n_jobs=-1)]: Done 135 out of 150 | elapsed: 73.1min remaining: 8.1min
[Parallel(n_jobs=-1)]: Done 150 out of 150 | elapsed: 85.7min finished
我现在无法重复分析，但我假设并行化是由于 RandomizedSearchCV() 中的 n_jobs=1 而发生的。
我对并行计算知之甚少。我知道 RandomizedSearchCV() 独立运行每个参数设置，但它在并行化时具体如何工作？那么 n_jobs=-1 和 XGBClassifier() 呢？在两个函数中都设置这个参数有意义吗？
Q: Does it make sense to set this parameter in both functions?
一个简短的版本：不，它没有。
较长的版本需要了解一下 n_jobs 的实际处理方式。
有一些昂贵的资源（对，CPU-cores 本身，最快和最昂贵的 CPU-core-local 缓存层次结构元素（不会深入研究 cache-lines以及它们在这个级别各自的关联性）和更便宜但也更慢的 RAM-memory ）， n_jobs = -1 指令，在第一个 call-signature 执行, 将立即获取所有这些资源。
这意味着，将没有合理的 "free" 资源用于任何 "deeper" 级别的尝试使用 -再次- "as many resources" 物理可用（ n_jobs = -1 再次执行并遵守，但是没有 "free" 从第一个中脱颖而出，在极其 "over-subscribed"（超载队列很少有实际（因此在任何不久的将来都不会免费）资源来利用的任务）O/S 的并发性 task-scheduler 的调度尝试映射/逐出/映射/逐出/映射/逐出因此在相同的真实（并且已经很忙）硬件元素上有更多的处理工作。
通常即使是第一次尝试也可能会在 RAM-allocations 方面造成麻烦，因为大型模型在过程实例化期间需要在所有 RAM-data-structures 中进行多次复制（整个副本有效地制作了所有对象，使用或未使用，复制到每个新进程中），作为 CPU-cores "dictates" 的数量。由此产生的内存交换绝对是您永远不会喜欢重复的事情。
享受模型 HyperParameters 的调整 - 它是机器学习实践的精华。值得擅长