Lentidão do mclapply() em alguns casos, mas não em outros
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo). Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065 Com o mcapply foi de: 1> tempoB[3] elapsed 2.135 Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this. If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options. No meu computador: getOption("cores") NULL Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2 Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302 Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249 Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205 ===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195 system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento. #### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902 system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 #### Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel). Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply? Abraços, Adriano S. Melo Ecologia - UFG
Colegas, Enviei o e-mail abaixo mas não recebi resposta. Desconfio que tenha sido devido ao tamanho da mensagem. Segue uma versão resumida do problema. Uso Ubuntu 12.04. Aparentemente, o maclapply (pacotes multicore ou parallel) tem desempenho distinto dependendo do código: ## Aqui o mclapply foi mais bem mais lento que um for loop: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195 system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 ### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902 system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply? Abraços e grato por qualquer ajuda, Adriano Ecologia - UFG Em 25 de novembro de 2012 18:21, Adriano S. Melo <asm.adrimelo@gmail.com> escreveu:
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo).
Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065
Com o mcapply foi de: 1> tempoB[3] elapsed 2.135
Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this.
If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options.
No meu computador: getOption("cores") NULL
Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2
Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302
Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249
Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205
===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento.
#### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 ####
Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel).
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços, Adriano S. Melo Ecologia - UFG
use o argumento mc.cores no mclapply e veja o q acontece. 2012/11/27 Adriano S. Melo <asm.adrimelo@gmail.com>
Colegas, Enviei o e-mail abaixo mas não recebi resposta. Desconfio que tenha sido devido ao tamanho da mensagem. Segue uma versão resumida do problema. Uso Ubuntu 12.04.
Aparentemente, o maclapply (pacotes multicore ou parallel) tem desempenho distinto dependendo do código:
## Aqui o mclapply foi mais bem mais lento que um for loop: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835
### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços e grato por qualquer ajuda, Adriano Ecologia - UFG
Em 25 de novembro de 2012 18:21, Adriano S. Melo <asm.adrimelo@gmail.com> escreveu:
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo).
Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065
Com o mcapply foi de: 1> tempoB[3] elapsed 2.135
Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this.
If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options.
No meu computador: getOption("cores") NULL
Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2
Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302
Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249
Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205
===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento.
#### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 ####
Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel).
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços, Adriano S. Melo Ecologia - UFG
R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
Adriano, Veja que com certeza a vantagem do mclapply vai depender de como você engendrou sua paralelização, explico: a vantagem não é efetiva pois existe um tempo que o processador vai demorar " distribuindo" as tarefas entre processadores! Você deve observar isso! Vou citar um caso. Imagine ter que realizar 1000 simulações em 10 cenários (entenda cenários como uma alteração dos parâmetros da simulação) e seja uma máquina com 5 processadores. Nesse caso, posso pensar em realizar uma paralelização de duas formas (deve haver mais, mas isso não evm ao caso). Uma delas seria, colocar um laço (for, por exemplo), entre os cenários e distribuir as 1000 simulações entre os 4 processadores e cada um faria 200 destas. Ou então, distribuir os cenários entre os 5 processadores, o que ele faria em duas vezes e então usar um laço para cada uma das 1000 simulações. Como você pode observar no primeiro caso estão envolvidos MUITO mais distribuições de códigos entre processadores que no primeiro, portanto, para a mesma tarefa, com os mesmos recursos computacionais teremos tempos bastante distintos. Essa distinção de tempo também leva em conta o próprio tempo da tarefa, se por acaso cada simulação leva um tempo "pequeno" acho (O Benilton pode confirmar ou descordar :) ), a segunda opção seria bem mais vantajosa, mas se cada simulação demorar "bastante" os tempos tendem a acabar se compensando! Espero ter sido claro! Fico à disposição (parafraseando o Walmes). att, FH 2012/11/27 Adriano S. Melo <asm.adrimelo@gmail.com>
Colegas, Enviei o e-mail abaixo mas não recebi resposta. Desconfio que tenha sido devido ao tamanho da mensagem. Segue uma versão resumida do problema. Uso Ubuntu 12.04.
Aparentemente, o maclapply (pacotes multicore ou parallel) tem desempenho distinto dependendo do código:
## Aqui o mclapply foi mais bem mais lento que um for loop: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835
### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços e grato por qualquer ajuda, Adriano Ecologia - UFG
Em 25 de novembro de 2012 18:21, Adriano S. Melo <asm.adrimelo@gmail.com> escreveu:
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo).
Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065
Com o mcapply foi de: 1> tempoB[3] elapsed 2.135
Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this.
If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options.
No meu computador: getOption("cores") NULL
Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2
Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302
Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249
Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205
===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento.
#### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 ####
Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel).
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços, Adriano S. Melo Ecologia - UFG
R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
Benilton: Repeti o código numa maquina diferente (um desktop, Ubuntu antigo, 10.04). Nem cheguei a usar o mc.core. O resultado no caso anomalo agora voltou ao normal: o mclapply reduziu o tempo pela metade (tenho 2 CPUs). Não sei o que aconteceu com o meu notebook que usei para rodar o código no fim de semana (lembro de ter repetido mais de uma vez)... Fernando: Muito obrigado pela dica. Vou levar isto em consideração nas minhas programações. abraços, Adriano Ecologia - UFG Em 27 de novembro de 2012 11:10, FHRB Toledo <fernandohtoledo@gmail.com> escreveu:
Adriano,
Veja que com certeza a vantagem do mclapply vai depender de como você engendrou sua paralelização, explico: a vantagem não é efetiva pois existe um tempo que o processador vai demorar " distribuindo" as tarefas entre processadores! Você deve observar isso!
Vou citar um caso.
Imagine ter que realizar 1000 simulações em 10 cenários (entenda cenários como uma alteração dos parâmetros da simulação) e seja uma máquina com 5 processadores. Nesse caso, posso pensar em realizar uma paralelização de duas formas (deve haver mais, mas isso não evm ao caso). Uma delas seria, colocar um laço (for, por exemplo), entre os cenários e distribuir as 1000 simulações entre os 4 processadores e cada um faria 200 destas. Ou então, distribuir os cenários entre os 5 processadores, o que ele faria em duas vezes e então usar um laço para cada uma das 1000 simulações.
Como você pode observar no primeiro caso estão envolvidos MUITO mais distribuições de códigos entre processadores que no primeiro, portanto, para a mesma tarefa, com os mesmos recursos computacionais teremos tempos bastante distintos. Essa distinção de tempo também leva em conta o próprio tempo da tarefa, se por acaso cada simulação leva um tempo "pequeno" acho (O Benilton pode confirmar ou descordar :) ), a segunda opção seria bem mais vantajosa, mas se cada simulação demorar "bastante" os tempos tendem a acabar se compensando!
Espero ter sido claro! Fico à disposição (parafraseando o Walmes).
att, FH
2012/11/27 Adriano S. Melo <asm.adrimelo@gmail.com>
Colegas,
Enviei o e-mail abaixo mas não recebi resposta. Desconfio que tenha sido devido ao tamanho da mensagem. Segue uma versão resumida do problema. Uso Ubuntu 12.04.
Aparentemente, o maclapply (pacotes multicore ou parallel) tem desempenho distinto dependendo do código:
## Aqui o mclapply foi mais bem mais lento que um for loop: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835
### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços e grato por qualquer ajuda, Adriano Ecologia - UFG
Em 25 de novembro de 2012 18:21, Adriano S. Melo <asm.adrimelo@gmail.com> escreveu:
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo).
Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065
Com o mcapply foi de: 1> tempoB[3] elapsed 2.135
Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this.
If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options.
No meu computador: getOption("cores") NULL
Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2
Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302
Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249
Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205
===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento.
#### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 ####
Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel).
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços, Adriano S. Melo Ecologia - UFG
R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
_______________________________________________ R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
A dica ainda continua: user mc.core=<numero de nucleos> 2012/11/27 Adriano S. Melo <asm.adrimelo@gmail.com>
Benilton: Repeti o código numa maquina diferente (um desktop, Ubuntu antigo, 10.04). Nem cheguei a usar o mc.core. O resultado no caso anomalo agora voltou ao normal: o mclapply reduziu o tempo pela metade (tenho 2 CPUs). Não sei o que aconteceu com o meu notebook que usei para rodar o código no fim de semana (lembro de ter repetido mais de uma vez)...
Fernando: Muito obrigado pela dica. Vou levar isto em consideração nas minhas programações.
abraços, Adriano Ecologia - UFG
Em 27 de novembro de 2012 11:10, FHRB Toledo <fernandohtoledo@gmail.com> escreveu:
Adriano,
Veja que com certeza a vantagem do mclapply vai depender de como você engendrou sua paralelização, explico: a vantagem não é efetiva pois existe um tempo que o processador vai demorar " distribuindo" as tarefas entre processadores! Você deve observar isso!
Vou citar um caso.
Imagine ter que realizar 1000 simulações em 10 cenários (entenda cenários como uma alteração dos parâmetros da simulação) e seja uma máquina com 5 processadores. Nesse caso, posso pensar em realizar uma paralelização de duas formas (deve haver mais, mas isso não evm ao caso). Uma delas seria, colocar um laço (for, por exemplo), entre os cenários e distribuir as 1000 simulações entre os 4 processadores e cada um faria 200 destas. Ou então, distribuir os cenários entre os 5 processadores, o que ele faria em duas vezes e então usar um laço para cada uma das 1000 simulações.
Como você pode observar no primeiro caso estão envolvidos MUITO mais distribuições de códigos entre processadores que no primeiro, portanto, para a mesma tarefa, com os mesmos recursos computacionais teremos tempos bastante distintos. Essa distinção de tempo também leva em conta o próprio tempo da tarefa, se por acaso cada simulação leva um tempo "pequeno" acho (O Benilton pode confirmar ou descordar :) ), a segunda opção seria bem mais vantajosa, mas se cada simulação demorar "bastante" os tempos tendem a acabar se compensando!
Espero ter sido claro! Fico à disposição (parafraseando o Walmes).
att, FH
2012/11/27 Adriano S. Melo <asm.adrimelo@gmail.com>
Colegas,
Enviei o e-mail abaixo mas não recebi resposta. Desconfio que tenha sido devido ao tamanho da mensagem. Segue uma versão resumida do problema. Uso Ubuntu 12.04.
Aparentemente, o maclapply (pacotes multicore ou parallel) tem desempenho distinto dependendo do código:
## Aqui o mclapply foi mais bem mais lento que um for loop: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835
### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços e grato por qualquer ajuda, Adriano Ecologia - UFG
Em 25 de novembro de 2012 18:21, Adriano S. Melo <asm.adrimelo@gmail.com> escreveu:
Colegas, Estou com um problema de lentidão no uso do mclapply do pacote multicore. Uso Ubuntu 12.04 em Dell Latitude E6500, 4Gb Ram e processador Centrino2. Trabalho com R no gedit (repeti algumas coisas diretamente no R executado no terminal mas não mudou nada). Já brinquei bastante com o comando, mas ainda não consegui entender exatamente o que está acontecendo (veja que fiz vários testes abaixo).
Seguindo uma mensagem anterior desta lista (18out12), executei o codigo do Fernando H. Toledo em: http://ridiculas.wordpress.com/2011/10/23/paralelizacao-de-processos/ O tempo de processammento SEM mcapply foi de: 1> tempoA[3] elapsed 2.065
Com o mcapply foi de: 1> tempoB[3] elapsed 2.135
Visto que o tempo do mclapply foi até maior, tentei descobrir o que estava acontecendo. Achei isto (https://github.com/markmfredrickson/RItools/issues/2): "My understanding is that multicore first checks to see if the mc.cores argument is set. If so, it uses that value. Next, it checks options("cores"), if this is set, it will use that value. If neither condition is true, it runs detectCores() itself. So in general, we do not need to manually detect cores. The multicore help page has more details on this.
If you want to override in RItools, you have two options. 1) options("cores" = 2) -- multicore will respect this. 2) options("RItools-apply" = function(lst, f) { mclapply(lst, f, mc.cores= 2) }). You can also use the second strategy to set other mclapply options.
No meu computador: getOption("cores") NULL
Usei a sugestão 1) acima: options("cores" = 2) getOption("cores") [1] 2
Executei o código novamente, mas não adiantou: 1> tempoA[3] elapsed 2.197 1> tempoB[3] elapsed 2.302
Usei a sugestão 2) acima, mas também não adiantou: 1> tempoA[3] elapsed 2.172 1> tempoB[3] elapsed 2.249
Fechei tudo e repeti os comandos usando o mclapply do pacote parallel. Ele não reconheceu o número de CPUs e portanto coloquei como argumento: mc.cores = 2 Melhorou apenas um pouquinho: 1> tempoA[3] elapsed 2.22 1> tempoB[3] elapsed 2.205
===>> Continuei brincando com o mclapply e vi que as coisas podem ser diferentes: system.time({ a<-mclapply(1:1000, function(numero) sd(rnorm(100000))) }) usuário sistema decorrido 528.277 4.544 92.195
system.time({ a<-vector('list', 1000) for (i in 1:1000){a[[i]]<-sd(rnorm(100000))} }) usuário sistema decorrido 16.301 0.520 16.835 #### Notem que aqui o mclapply foi BEM lento.
#### Mas neste exemplo abaixo ele reduziu o tempo pela metade (como esperado, visto que tenho 2 CPUs): library(vegan) data(BCI) system.time({ a<-mclapply(1:100, function(numero) nestednodf(BCI)) }) usuário sistema decorrido 127.996 2.520 47.902
system.time({ a<-vector('list', 100) for (i in 1:100){a[[i]]<-nestednodf(BCI)} }) usuário sistema decorrido 82.765 0.352 83.204 ####
Eu tenho 2 CPUs: 1> detectCores() # função do pacote parallel [1] 2 No Monitor do Sistema pude observar que de fato o mclapply está usando as duas CPUs para processamento (tanto com multicore quanto com parallel).
Sugestões do que pode estar acontecendo? Em que situação vale a pena usar o mclapply?
Abraços, Adriano S. Melo Ecologia - UFG
R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
_______________________________________________ R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
R-br mailing list R-br@listas.c3sl.ufpr.br https://listas.inf.ufpr.br/cgi-bin/mailman/listinfo/r-br Leia o guia de postagem (http://www.leg.ufpr.br/r-br-guia) e forneça código mínimo reproduzível.
participantes (3)
-
Adriano S. Melo -
Benilton Carvalho -
FHRB Toledo