Gestion des tâches de cluster dans R via le package futur

Question

Je souhaite utiliser le package Rfuture (prend en charge les calculs asynchrones) pour créer un serveur de jobs de cluster pouvant ajouter/supprimer dynamiquement des travaux dans une file d'attente.

Une fonctionnalité spécifique que je voudrais ajouter à mon serveur de jobs consiste à distribuer des tâches demandant de la mémoire aux machines les plus puissantes de mon cluster. Cependant, comme je n'ai aucune expérience avec le paquet, je ne suis pas sûr que mon approche (donnée ci-dessous) comporte des pièges. Plus précisément, est-ce que les appels suivants de plan ont des effets secondaires qui pourraient gâcher les choses? S'il vous plaît voir les commentaires dans le code pour plus de détails.

Merci d'avance!

library(parallel) 
library(future) 

slaveIPs=c("172.16.2.10","172.16.2.21") 
masterIP="172.16.2.33" 
workers=makePSOCKcluster(slaveIPs,master=masterIP) 

#check whether PSOCK cluster was correctly set up 
unlist(clusterCall(workers,function(x) unname(Sys.info()["nodename"])) 
#[1] "ip-172-16-2-10" "ip-172-16-2-21" 

#now the first important part that I am not sure about 
#as you can see, I only use workers[1] for the first task 
#is it OK to use workers[1] like that? 
plan(cluster,workers=workers[1]) 

f=future({ 
    #do memory-hungry work 
    unname(Sys.info()["nodename"]) 
}) 

message(value(f)) 
#ip-172-16-2-10 

#now I am only using workers[2] for the second task 
#Is this ok? Does the previous call to 'plan' need some cleaning before? 
plan(cluster,workers=workers[2]) 

f=future({ 
    #do low-memory work 
    unname(Sys.info()["nodename"]) 
}) 

message(value(f)) 
#ip-172-16-2-21 

stopCluster(workers) 

Answer 1

Auteur de future ici:

Oui, il va bien de modifier les stratégies futures comme ça, à savoir en utilisant plan(). Une alternative est d'utiliser:

f <- cluster({ 
    #do low-memory work 
    unname(Sys.info()["nodename"]) 
}, workers = workers[2]) 

qui est fondamentalement ce qui se passe en interne. L'inconvénient de spécifier explicitement de futures stratégies comme celle-ci est que votre code sera codé en dur pour utiliser les contrats à terme cluster.

Pour votre information, je prévois d'ajouter un mécanisme quelconque pour spécifier les «ressources» préférées ou requises par avenir. Ceci est juste conceptuelle pour l'instant et existe pas de sitôt, mais je pense à quelque chose en ligne avec:

f <- future({ ... }, needs = "himem") 

où l'on peut interroger les travailleurs de la balise himem/propriété, par exemple attr(workers[2], "provides") <- c("himem", "superfast"). Je partage ces pensées juste pour que tu saches que je suis conscient de besoins comme le tien. Encore une fois, il faudra beaucoup de temps avant que de tels mécanismes soient disponibles, alors entre-temps, vous devez spécifier explicitement la stratégie future comme ci-dessus.

BTW, au lieu de:

slaveIPs=c("172.16.2.10","172.16.2.21") 
masterIP="172.16.2.33" 
workers=makePSOCKcluster(slaveIPs,master=masterIP) 

vous pouvez essayer:

slaveIPs <- c("172.16.2.10", "172.16.2.21") 
workers <- makeClusterPSOCK(slaveIPs) 

fourni par le paquet future - cela évite d'avoir à connaître/spécifier l'adresse IP du maître.