Tentativo di iniziare con doParallel e foreach ma nessun miglioramento

Question

Sto cercando di utilizzare il pacchetto doParallel e foreach ma sto ottenendo una riduzione delle prestazioni utilizzando l'esempio di bootstrap nella guida trovata qui CRANpage.

library(doParallel) 
library(foreach) 
registerDoParallel(3) 
x <- iris[which(iris[,5] != "setosa"), c(1,5)] 
trials <- 10000 
ptime <- system.time({ 
    r <- foreach(icount(trials), .combine=cbind) %dopar% { 
    ind <- sample(100, 100, replace=TRUE) 
    result1 <- glm(x[ind,2]~x[ind,1], family=binomial(logit)) 
    coefficients(result1) 
    } 
    })[3] 
ptime 

Questo esempio restituisce 56.87.

Quando cambio lo dopar a solo do per eseguirlo in sequenza anziché in parallelo, restituisce 36.65.

Se si esegue registerDoParallel(6), il tempo parallelo scende a 42.11 ma è ancora più lento di quello sequenziale. registerDoParallel(8) diventa 40.31 ancora peggio del sequenziale.

Se aumento trials a 100.000, la sequenza sequenziale prende 417.16 e l'esecuzione parallela con 3 lavoratori richiede 597.31. Con 6 lavoratori in parallelo ci vuole 425.85.

Il mio sistema è

• Dell Optiplex 990

• Windows 7 Professional a 64 bit

• 16 GB di RAM

• Intel i-7-2600 3.6GHz Quad nucleo con hyperthreading

Sto facendo qualcosa di sbagliato qui? Se faccio la cosa più inventata che io possa pensare (sostituendo il codice computazionale con Sys.sleep(1)), ottengo una riduzione effettiva strettamente proporzionata al numero di lavoratori. Mi chiedo perché l'esempio nella guida diminuisca le prestazioni per me mentre per loro ha accelerato le cose?

Answer 1

Il problema sottostante è che doParallel esegue attach per ogni esecuzione di attività sui lavoratori del cluster PSOCK per aggiungere le variabili esportate al percorso di ricerca del pacchetto. Questo risolve diversi problemi di scoping, ma può danneggiare significativamente le prestazioni, in particolare con attività di breve durata e grandi quantità di dati esportati. Questo non si verifica su Linux e Mac OS X con il tuo esempio, poiché useranno mclapply, anziché clusterApplyLB, ma si verificherà su tutte le piattaforme se si registra esplicitamente un cluster PSOCK.

Credo di aver capito come risolvere i problemi di scoping dell'attività in modo diverso che non danneggia le prestazioni e sto lavorando con Revolution Analytics per ottenere la correzione nella prossima versione di doParallel e doSNOW , che ha anche lo stesso problema.

È possibile aggirare il problema utilizzando compito suddivisione in blocchi:

ptime2 <- system.time({ 
    chunks <- getDoParWorkers() 
    r <- foreach(n=idiv(trials, chunks=chunks), .combine='cbind') %dopar% { 
    y <- lapply(seq_len(n), function(i) { 
     ind <- sample(100, 100, replace=TRUE) 
     result1 <- glm(x[ind,2]~x[ind,1], family=binomial(logit)) 
     coefficients(result1) 
    }) 
    do.call('cbind', y) 
    } 
})[3] 

Questo si traduce in un solo compito per lavoratore, per cui ogni lavoratore esegue solo attach una volta, piuttosto che trials/3 volte.Ciò comporta anche meno operazioni di socket più grandi, che possono essere eseguite in modo più efficiente sulla maggior parte dei sistemi, ma in questo caso il problema critico è attach.