A dica ainda continua: user mc.core=<numero de nucleos>
2012/11/27 Adriano S. Melo <[email protected]> > 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 > <[email protected]> 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 <[email protected]> > >> > >> 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 > >> <[email protected]> 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 > >> [email protected] > >> 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 > > [email protected] > > 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 > [email protected] > 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 [email protected] 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.
