On 01/16/2012 08:00 AM, Simon Urbanek wrote: > On Jan 16, 2012, at 9:02 AM, Prashantha Hebbar wrote: > >> Hello friends, >> I was tryig to parallize a function using mclapply. But I find lapply() executes in lesser time than mclapply(). I have given here my system time taken for both the functions. >>> library(ShortRead) >>> library(multicore)> fqFiles<- list.files("./test") >>> system.time(lapply(fqFiles, function(fqFiles){ >> readsFq<- readFastq(dirPath="./test",pattern=fqFiles) >> })) >> user system elapsed >> 0.399 0.021 0.419 >>> system.time(mclapply(fqFiles, function(fqFiles){ >> readsFq<- readFastq(dirPath="./test",pattern=fqFiles)},mc.cores=3)) >> user system elapsed >> 0.830 0.151 0.261 >> >> Since the ./test directory contains three fastq files. I have used mc.cores = 3. >> >> here is my mpstat output for mclapply() >> >> 04:47:55 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s >> 04:47:56 PM all 13.86 0.00 1.37 0.00 0.00 0.00 0.00 84.77 1023.23 >> 04:47:56 PM 0 21.21 0.00 2.02 0.00 0.00 0.00 0.00 76.77 1011.11 >> 04:47:56 PM 1 33.00 0.00 2.00 0.00 0.00 0.00 0.00 65.00 9.09 >> 04:47:56 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00 >> 04:47:56 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 3.03 >> 04:47:56 PM 4 3.03 0.00 2.02 0.00 0.00 0.00 0.00 94.95 0.00 >> 04:47:56 PM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00 >> 04:47:56 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00 >> 04:47:56 PM 7 53.00 0.00 4.00 0.00 0.00 0.00 0.00 43.00 0.00 >> >> Hence,Can you please suggest me, why mclapply has taken more time than lapply()? In case it's not clear, the system.time 'elapsed' time shows that mclapply *is* faster overall ('wall clock') -- I would have only .261 seconds to go for coffee, compared to .419 with lapply. As Simon suggests, a much more common paradigm is to put more work in to the function evaluated by lapply --, e.g., calculating qa() -- and then returning the result of the computation, typically a much smaller summary of the bigger data. Even in this case, your computer will need to have enough memory to hold all the fastq data in memory; for some purposes it will make more sense to use FastqSampler and FastqStreamer to iterate over your file. Martin > > multicore is designed for parallel *computing* which is not what you do. For serial tasks (like yours) it will be always slower, because it needs to a) spawn processes b) read the data (serially since you use the same location) c) serialize all the data and send it to the master process, d) unserialize and concatenate all the data in the master process to a list. If you run lapply it does only b) which is in your case not the slowest part. Using multicore makes only sense if you actually perform computations (or any parallel task). > > Cheers, > Simon > > >> Thanking you in anticipation. >> Regards, >> Prashantha >> Prashantha Hebbar Kiradi, >> >> E-mail: prashantha.hebbar at dasmaninstitute.org >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-hpc mailing list >> R-sig-hpc at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-hpc > > _______________________________________________ > R-sig-hpc mailing list > R-sig-hpc at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-hpc -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793