Parallele Verarbeitung mit xgboost und caret

Question

Ich möchte den Modellanpassungsprozess für xgboost während der Verwendung von Caret parallelisieren. Von dem, was ich in xgboosts documentation gesehen habe, steuert der Parameter nthread die Anzahl der Threads, die verwendet werden sollen, während die Modelle in dem Sinne angepasst werden, dass die Bäume parallel aufgebaut werden. Caret's train Funktion führt eine Parallelisierung in dem Sinne durch, dass beispielsweise ein Prozess für jede Iteration in einem k-fachen CV ausgeführt wird. Ist das Verständnis korrekt, wenn ja, es ist besser:

1. die Anzahl der Kerne Register (zum Beispiel mit dem doMC Paket und die registerDoMC Funktion), setzte nthread=1 über Zug-Funktion des caret so passiert es, dass Parameter xgboost, setze allowParallel=TRUE in trainControl, und lasse caret die Parallelisierung für die Kreuzvalidierung durchführen; oder
2. Deaktivieren Sie die Caret-Parallelisierung (allowParallel=FALSE und keine parallele Back-End-Registrierung) und setzen Sie nthread auf die Anzahl der physischen Kerne, so dass die Parallelisierung ausschließlich innerhalb von Xgboost enthalten ist.

Oder gibt es keinen "besseren" Weg, die Parallelisierung durchzuführen?

Edit: lief ich den Code von @topepo vorgeschlagen, mit tuneLength = 10 und search="random" und nthread=1 in der letzten Zeile der Angabe (sonst verstehe ich, dass xgboost Multithreading verwenden). Es sind die Ergebnisse, die ich bekam:

xgb_par[3] 
elapsed 
283.691 
just_seq[3] 
elapsed 
276.704 
mc_par[3] 
elapsed 
89.074 
just_seq[3]/mc_par[3] 
elapsed 
3.106451 
just_seq[3]/xgb_par[3] 
elapsed 
0.9753711 
xgb_par[3]/mc_par[3] 
elapsed 
3.184891 

Am Ende stellte sich heraus, dass sowohl für meine Daten und für diesen Testfall, lassen caret behandeln die Parallelisierung eine bessere Wahl in Bezug auf die Laufzeit war.

Answer 1

Es ist nicht einfach zu projizieren, was die beste Strategie wäre. Mein (voreingenommener) Gedanke ist, dass Sie den Prozess, der am längsten dauert, parallelisieren sollten. Hier wäre das die Resampling-Schleife, da ein offener Thread/Worker das Modell viele Male aufrufen würde. Der gegenteilige Ansatz der Parallelisierung der Modellanpassung wird Arbeiter wiederholt starten und stoppen und theoretisch Dinge verlangsamen. Ihre Laufleistung kann variieren.

Ich habe nicht OpenMP installiert, aber es gibt Code unten zu testen (wenn Sie Ihre Ergebnisse melden könnten, wäre das hilfreich).

library(caret) 
library(plyr) 
library(xgboost) 
library(doMC) 

foo <- function(...) { 
    set.seed(2) 
    mod <- train(Class ~ ., data = dat, 
       method = "xgbTree", tuneLength = 50, 
       ..., trControl = trainControl(search = "random")) 
    invisible(mod) 
} 

set.seed(1) 
dat <- twoClassSim(1000) 

just_seq <- system.time(foo()) 


## I don't have OpenMP installed 
xgb_par <- system.time(foo(nthread = 5)) 

registerDoMC(cores=5) 
mc_par <- system.time(foo()) 

Meine Ergebnisse (ohne OpenMP)

> just_seq[3] 
elapsed 
326.422 
> xgb_par[3] 
elapsed 
319.862 
> mc_par[3] 
elapsed 
102.329 
> 
> ## Speedups 
> xgb_par[3]/mc_par[3] 
elapsed 
3.12582 
> just_seq[3]/mc_par[3] 
elapsed 
3.189927 
> just_seq[3]/xgb_par[3] 
elapsed 
1.020509