search for: future_lapply

...ecs, so we know our parallel code works regardless of which of these backends the user picks. Now, based on these basic future low-level functions, other higher level APIs have been implemented. For instance, the future.apply packages provides futurized version of all base R apply functions, e.g. future_lapply(), future_vapply(), future_Map(), etc. You can basically take you lapply(...) code and replace it with future_lapply(...) and things will just work. So, try replacing your current mclapply() with future_lapply(). If you/the user uses the 'multicore' backend - set by plan(multicore) at to...

Thanks Simon, I will take note of the sensible default for core usage. I?m trying to achieve small scale parallelism, where tasks take 1-5 seconds and make fuller use of consumer hardware. Its not a HPC-worthy computation but even laptops these days come with 4 cores and I don?t see a reason to not make use of it. The goal for the current piece of code I?m working on is to bootstrap many

...ts, nbrOfChunks), length) [1] 5 5 5 5 4 5 5 5 5 5 4 5 5 5 5 4 5 5 5 5 However, there are multiple alternatives between the two extremes, e.g. > nbrOfChunks <- scale * nbrOfElements / nbrOfWorkers So, is there a reason why you argue for scale = 1.0 to be the optimal? FYI, In future.apply::future_lapply(X, FUN, ...) there is a 'future.scheduling' scale factor(*) argument where default future.scheduling = 1 corresponds to (B) and future.scheduling = +Inf to (A). Using future.scheduling = 4 achieves the amount of load-balancing you propose in (C). (*) Different definition from the above &...

...5 4 5 5 5 5 >> >> However, there are multiple alternatives between the two extremes, e.g. >> >>> nbrOfChunks <- scale * nbrOfElements / nbrOfWorkers >> So, is there a reason why you argue for scale = 1.0 to be the optimal? >> >> FYI, In future.apply::future_lapply(X, FUN, ...) there is a >> 'future.scheduling' scale factor(*) argument where default >> future.scheduling = 1 corresponds to (B) and future.scheduling = +Inf >> to (A). Using future.scheduling = 4 achieves the amount of >> load-balancing you propose in (C). (*) D...

...5 5 5 4 5 5 5 5 5 4 5 5 5 5 4 5 5 5 5 > >However, there are multiple alternatives between the two extremes, e.g. > >> nbrOfChunks <- scale * nbrOfElements / nbrOfWorkers > >So, is there a reason why you argue for scale = 1.0 to be the optimal? > >FYI, In future.apply::future_lapply(X, FUN, ...) there is a >'future.scheduling' scale factor(*) argument where default >future.scheduling = 1 corresponds to (B) and future.scheduling = +Inf >to (A). Using future.scheduling = 4 achieves the amount of >load-balancing you propose in (C). (*) Different definition...

...t;>> However, there are multiple alternatives between the two extremes, e.g. >>> >>>> nbrOfChunks <- scale * nbrOfElements / nbrOfWorkers >>> So, is there a reason why you argue for scale = 1.0 to be the optimal? >>> >>> FYI, In future.apply::future_lapply(X, FUN, ...) there is a >>> 'future.scheduling' scale factor(*) argument where default >>> future.scheduling = 1 corresponds to (B) and future.scheduling = +Inf >>> to (A).? Using future.scheduling = 4 achieves the amount of >>> load-balancing you propose...

Dear R-Devel List, **TL;DR:** The function **parLapplyLB** of the parallel package has [reportedly][1] (see also attached RRD output) not been doing its job, i.e. not actually balancing the load. My colleague Dirk Sarpe and I found the cause of the problem and we also have a patch to fix it (attached). A similar fix has also been provided [here][2]. [1]:

On Mon, Feb 26, 2018 at 3:25 PM, Gary Black <gwblack001 at sbcglobal.net> wrote: (Sorry to be a bit slow responding.) You have not supplied a complete example, which would be good in this case because what you are suggesting could be a serious bug in R or a package. Serious journals require reproducibility these days. For example, JSS is very clear on this point. To your question >