背景

Question

关于R中并行后端的2个问题：

1）parallel::detectCores()未检测到我的计算机上正确的核心数：

    parallel::detectCores(logical = FALSE)
    [1] 24
    parallel::detectCores(logical = TRUE)
    [1] 48

2）运行插入符号模型时，每当我选择超过64个核心时，即使每个进程都已成功完成（因为它出现在日志中），模型也无法完成。无论我在32核计算机上尝试使用多少核心，我都会发生这种情况，当我运行makeCluster(64)时，它运行正常，makeCluster(65)挂起。

library(caret)
library(doParallel)
library(xgboost)

iris <- iris[1:100,]
iris$Species <- as.factor(as.character(iris$Species))

tc <- trainControl(method="repeatedcv", 
                   classProb = TRUE, 
                   verboseIter = TRUE,
                   allowParallel = TRUE)

stopCluster(cl)
cl <- makeCluster(65, outfile="D:\\R_data\\Log\\test.txt")
registerDoParallel(cl)

system.time(
    train.rf <- train(Species ~ .,data=iris, method="xgbTree", trControl=tc, metric = "Accuracy", verbose = TRUE)
)

上面会持续20-30分钟或更长时间，永远不会执行，而下面的代码会在20秒内完成：

> cl <- makeCluster(64, outfile="D:\\R_data\\Log\\test2.txt")
> registerDoParallel(cl)
> system.time(
    +         train.rf <- train(Species ~ .,data=iris, method="xgbTree", trControl=tc, metric = "Accuracy", verbose = TRUE)
    +     )
Aggregating results
Selecting tuning parameters
Fitting nrounds = 50, max_depth = 1, eta = 0.3, gamma = 0, colsample_bytree = 0.6, min_child_weight = 1, subsample = 0.5 on full training set
user  system elapsed 
1.71    0.76   22.63

会话信息：

> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows Server >= 2012 x64 (build 9200)

locale:
    [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252    LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C                           LC_TIME=English_United States.1252    

attached base packages:
    [1] parallel  stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
    [1] doParallel_1.0.10 caret_6.0-78      ggplot2_2.2.1     lattice_0.20-34   doSNOW_1.0.14     snow_0.4-2        iterators_1.0.8   foreach_1.4.3    

loaded via a namespace (and not attached):
    [1] tidyselect_0.1.1    purrr_0.2.4         reshape2_1.4.2      kernlab_0.9-25      splines_3.3.3       colorspace_1.3-2    stats4_3.3.3       
[8] yaml_2.1.14         survival_2.41-3     prodlim_1.6.1       rlang_0.1.4         e1071_1.6-8         ModelMetrics_1.1.0  foreign_0.8-67     
[15] glue_1.1.1          withr_2.1.0         xgboost_0.6-4       bindrcpp_0.2        bindr_0.1           plyr_1.8.4          dimRed_0.1.0       
[22] lava_1.5.1          robustbase_0.92-7   stringr_1.2.0       timeDate_3042.101   munsell_0.4.3       gtable_0.2.0        recipes_0.1.1      
[29] codetools_0.2-15    psych_1.7.5         class_7.3-14        DEoptimR_1.0-8      broom_0.4.2         Rcpp_0.12.13        scales_0.4.1       
[36] ipred_0.9-6         CVST_0.2-1          ranger_0.8.0        mnormt_1.5-5        stringi_1.1.5       dplyr_0.7.4         RcppRoll_0.2.2     
[43] ddalpha_1.3.1       grid_3.3.3          tools_3.3.3         magrittr_1.5        lazyeval_0.2.0      tibble_1.3.4        randomForest_4.6-12
[50] tidyr_0.7.2         DRR_0.0.2           pkgconfig_2.0.1     MASS_7.3-45         Matrix_1.2-8        data.table_1.10.4   lubridate_1.7.1    
[57] gower_0.1.2         assertthat_0.2.0    R6_2.2.2            rpart_4.1-10        compiler_3.3.3      sfsmisc_1.1-1       nnet_7.3-12        
[64] nlme_3.1-131       
> version
_                           
platform       x86_64-w64-mingw32          
arch           x86_64                      
os             mingw32                     
system         x86_64, mingw32             
status                                     
major          3                           
minor          3.3                         
year           2017                        
month          03                          
day            06                          
svn rev        72310                       
language       R                           
version.string R version 3.3.3 (2017-03-06)
nickname       Another Canoe

谢谢你的帮助！

Answer 1

建议：

我的建议（虽然违反直觉）是减少分配给群集的核心数量。为什么？

你只有48个实际的物理核心，超线程（见下面的解释）暗示你有96个，但这并不一定意味着真正的好处（通常在15％到30％的净利益之间）随着核心数量的增加创造更多仲裁。

基本上，任何并行执行解决方案都隐含着通信和协调的成本。如果减少分配的核心数量，您会发现并行性和性能之间存在最佳点。

六十五个核心故障

为什么65而不是64核触发故障？我的感觉是你正在击中128 thread limit of Windows。解决方案是重新编译R或PRO和/或要求修复。根据网址：

这是最多127个节点的R限制（2015）。这不是Windows线程限制，但也可以通过内存限制来调用，因为每个rscript.exe（+ conhost.exe）每个需要至少44 MB的RAM。对于具有99个客户端的本地Windows雪群，需要4 GB RAM。

背景

为了解释这种情况，我的意思是我们必须退后一步，提供一些关于以下关系的背景：

操作系统依赖关系[Windows与Unix]
R OS依赖关系上下文中的包关系
- doParallel - ＆gt;平行 - ＆gt; SNOW
资源超额认购

平行:: detectCores（）

好的，使用它作为框架可以从parallel::detectCores()开始。这里的问题是Windows和Unix报告不同的结果。根据{{1}}手册：

在Windows上，默认设置是报告逻辑CPU的数量。在现代硬件（例如英特尔酷睿i7）上，后者可能并非不合理，因为超线程确实提供了显着的额外吞吐量。 parallel报告依赖于操作系统版本：在最新版本的Windows上报告物理内核的数量，但在旧版本上，它可能会报告物理CPU包的数量。

因此，您的结果意味着：

detectCores(logical = FALSE)

您有24个物理核心和48个逻辑核心。

让我们检查一下，你正在运行Intel Xeon E5-4640 v4。好吧，单个E5-4640 v4有12个CPU和24个逻辑线程。这意味着当您报告12 * 4 = 48 CPU，24 * 4 = 96个逻辑核心时，您正在运行四插槽计算机。

因此，您的操作系统（Windows）报告48个物理核心，您的R实例报告48个核心......物理核心（48）和逻辑核心（96）之间有什么区别？

嗯，在这种情况下，逻辑核心构成了一个有趣的难题。

Hyperthreading是英特尔为在单核上创建额外执行“线程”而开发的“创新”，并被报告为逻辑核心。它不会使核心功能翻倍，因为它实际上共享了许多单个组件，每次只能执行一个功能。但是，它可以执行指令设置等操作。因此，当核心正在执行已经设置的指令时，超线程可以设置另一条指令。值得注意的是，核心上只有一个可以执行指令的地方，所以它必须等待当前正在执行的指令才能完成。

我希望上述内容可以帮助您找到正确的方向。

进一步阅读：

R - 当使用#core核心时，插入符号中的模型没有完成。 64 in foreach＆amp; doParallel

1 个答案:

建议：

六十五个核心故障

背景

平行:: detectCores（）