Es:
library(future)
plan(multiprocess, workers = 4)
system.time({
a1 <- future({Sys.sleep(7); 1})
a2 <- future({Sys.sleep(1); 1})
a3 <- future({Sys.sleep(1); 1})
a4 <- future({Sys.sleep(1); 1})
a5 <- future({Sys.sleep(1); 1})
a6 <- future({Sys.sleep(1); 1})
a7 <- future({Sys.sleep(1); 1})
res <- sapply(list(a1, a2, a3, a4, a5, a6, a5), value)
})
Piensa antes las posibles opciones:
- ~8 segundos: ejecuta primero
a1
-a4
en 7 segundos y luegoa5
-a7
en un segundo adicional. - ~7 segundos: ejecuta primero
a1
-a4
, pero cuando acabana2
-a4
, lanzaa5
-a7
, que terminan antes quea1
- ¿Otras?
Vosotros mismos.
(Pensad que si la respuesta fuese ~7 segundos, podría hacerse esto directamente con future
).
Otra: ~7 segundos; a1-a7 se ejecutan simultáneamente y a2-a7 acaban antes que a1.
Ahora bien, ¿qué diferencia hay entre
workers=1
yworkers=2
? (En mi máquina, ninguna) ¿Por qué?¿Lo has ejecutado en sesiones de R distintas? Me ha parecido que no funciona lo de cambiar el número de «workers» en la misma sesión; se queda pillado en el valor que le pasas por primera vez.
Sobre tu otra opción de ejecución, habrá que pensar una prueba para ver si es cierta o no. Sospecho que no.
Perdón, tienes razón. Estaba con
workers=8
en la cabeza. Eso me pasa por leer en diagonal.Sí, y no hay diferencia: 13 segundos en ambos casos. No lo entiendo. ¿Cuánto te tarda a ti? Y he comprobado que sí pilla el nuevo valor de «workers» en la misma sesión.
13 segundos con un worker y 12.275 con dos. Raro, ¿no? ¿Overhead tal vez? Voy a escribir una prueba en que cada proceso escriba su pid y su momento de inicio y fin en un fichero externo. En algún momento.