similar to: Mclapply prints once

Dear all, In my 'simple' computer I was running some experiments to help me understand how faster a multicore lapply will be. I thought it might be interesting for some people to look at the results. Even though are not accurate, still might be a good indicator how much improvement there can be. A.Case. The classic: for 1:100 for (i in c(1:dimz)){ print(sprintf('Creating the %d

Dear all. I am using the mclapply function to split my code to the many cores my system has. It seems that is working fine. This is the parallel version of lcapply. The only problem that I seem to have is that the printf cannot print messages. The ideal to me is to have fro my function an output of the form Shadowlist<-mclapply(1:dimz, function(i) { print(sprintf('Creating the

Dear all, I would like to ask your help understand the subsequent steps for making my program faster. The following code: Gauslist<-array(data=NA,dim=c(dimx,dimy,dimz)) for (i in c(1:dimz)){ print(sprintf('Creating the %d map',i)); Gauslist[,,i]<-f <- GaussRF(x=x, y=y, model=model, grid=TRUE,param=c(mean,variance,nugget,scale,Whit.alpha)) } creates 100 GaussMaps (each

Regarding the following code, warning(sprintf(ngettext(has.errors, "scheduled core %s encountered error in user code, all values of the job will be affected", "scheduled cores %s encountered errors in user code, all values of the jobs will be affected"), paste(has.errors, collapse = ", ")), domain = NA) has.errors is a vector whose elements are the

Dear all I am looking for a shorter way and more elegant to write the following for (i in c(1:length(Shadowlist))){ filename<-paste('/home/apa/maps/',model,i,'.mat',sep="") varname<-paste(model,'_shadow',i,sep="") eval(parse(text=paste('writeMat(filename,',varname,'=Shadowlist[[i]])',sep=""))) } actually I do not

Dear all, I am trying to learn lapply. I would like, as a test case, to try the lapply alternative for the Shadowlist<-array(data=NA,dim=c(dimx,dimy,dimmaps)) for (i in c(1:dimx)){ Shadowlist[,,i]<-i } ---so I wrote the following--- returni <-function(i,ShadowMatrix) {ShadowMatrix<-i} lapply(seq(1:dimx),Shadowlist[,,seq(1:dimx)],returni) So far I do not get same results

Dear all, I am trying to multiply three different matrices and each matrice is of size 16384,16384 the normal %*% multiplciation operator has not finished one day now. As I am running a system with many cores (and it seems that R is using only one of those) I would like to write fast a brief function that converts the typical for loops of a matrix multiplication to a set of lapply sets (mclapply

Well it's only a leak if you don't get the memory back after it returns, right? Anyway, one (untested by me) possibility is the copying of memory pages when the garbage collector touches objects, as pointed out by Radford Neal here: http://r.789695.n4.nabble.com/Re-R-devel-Digest-Vol-149-Issue-22-td4710367.html If so, I don't think this would be easily avoidable, but there may be

Toby, > On Sep 2, 2015, at 1:12 PM, Toby Hocking <tdhock5 at gmail.com> wrote: > > Dear R-devel, > > I am running mclapply with many iterations over a function that modifies > nothing and makes no copies of anything. It is taking up a lot of memory, > so it seems to me like this is a bug. Should I post this to > bugs.r-project.org? > > A minimal reproducible

Dear Jeff, There was a problem in LYGH and lapply threw an error, but mclapply got stuck in an infinite loop. The doc for mclapply says that mclapply runs under try() with silent = TRUE. So that means mclapply should run properly, i.e output a try class object and exit. But it didn't. Can you shed some light on why this happened? THanking you, Yours sincerely, AKSHAY M

I've been using mclapply and have encountered situations where it gives errors or returns incorrect results. Here's a minimal example, which gives the error on R 2.15.2 on Mac and Linux: library(parallel) f <- function(x) NULL mclapply(1, f, mc.preschedule = FALSE, mc.cores = 1) # Error in sum(sapply(res, inherits, "try-error")) : # invalid 'type' (list) of argument

Hi, a few comments below. First, from my experience and troubleshooting similar reports from others, a returned NULL from parallel::mclapply() is often because the corresponding child process crashed/died. However, when this happens you should see a warning, e.g. > y <- parallel::mclapply(1:2, FUN = function(x) if (x == 2) quit("no") else x) Warning message: In

The attached diff address the following issues in mclapply mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be an efficient representation and is not required if the object implements length, [, and [[ methods (lapply must also work on the object, either through coercion to a list at the 'inner.do' level or through other means, e.g., promoting lapply to a

Dear members, I am using arfima in an mclapply construction (from the parallel package): Browse[2]> LYG <- mclapply(LYGH, FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:10], FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:2], FUN = arfima, mc.cores = detectCores()) ^C You can see that I am

Dear parallel users and developers, I might have encountered a bug in the function 'mclapply' of package 'parallel'. I construct a matrix using the same input data and code with a single difference: Once I use mclapply and the other time lapply. Shockingly the result is NOT the same. To evaluate please unpack the attached archive and execute Rscript mclapply_test.R I put the

Hello, I have been having issues using parallel::mclapply in a memory-efficient way and would like some guidance. I am using a 40 core machine with 96 GB of RAM. I've tried to run mclapply with 20, 30, and 40 mc.cores and it has practically brought the machine to a standstill each time to the point where I do a hard reset. When running mclapply with 10 mc.cores, I can see that each process

I think it's worth saying that mclapply() works as documented: it relies on forking, and so doesn't work well in environments where it's unsafe to fork. This is spelled out explicitly in the documentation of ?mclapply: It is strongly discouraged to use these functions in GUI or embedded environments, because it leads to several processes sharing the same GUI which will likely cause

Dear R-devel friends: I'm back to bother you again about the conflict between mclapply and tcltk. I've been monitoring several packages that want to use mclapply to parallelize computations and need to figure out what should be done. It appears tcltk cannot be safely unloaded, so the best we can do is check for the presence of tcltk and stop if it is found before mclapply() is used. I

Hi, there seem to be some (small) bugs in the mclapply function in parallel. I discovered this in the current R release version, and I checked that it is still present in R-devel. I think it only occurs in the part of the code corresponding to argument option mc.preschedule = FALSE. Here are two examples: a) library(parallel) mclapply(list(), identity, mc.preschedule=FALSE) Error in

Hi Thibault, mclapply has been designed to signal an error in two ways. User code errors are returned as special objects (of class "try-error") in the respective element of the result list. All other errors (including a process killed) are returned as NULL in the respective elements of the result list. To detect these errors reliably, one needs to implement FUN so that it never