search for: setdtthread

The following program is whittled down from a much larger program that always works on Intel, and always works on AMD's threadripper with lapply but not mclappy. With mclapply on AMD, all processes go into "suspend" mode and the program then hangs. This bug is replicable on an AMD Ryzen Threadripper 2950X 16-Core Processor (128GB RAM), running latest ubuntu 18.04. The R version

...t to this stage. I sure hope that I am not reporting an old bug... | | options("mc.cores"=4) | library(data.table) | library(parallel) Just how you set mc.cores to 4 for parallel::mclapply I would try throttling data.table which in its current version goes for all cores. So do, say, setDTthreads(4) and see if that helps. Try lower and lower values to see if you get by. While there may well be a different race condition in mclapply, it may help to not overschedule. (FWIW, the next version of data.table, in queue at CRAN, is less aggressive and has additional options for fine tuning.) Di...

...ork with Yan off list to see what the difference is. Either the fork catch isn't working in that environment for some reason, the use case is different to the tests somehow or the fork catch is working but something somewhere is asserting its surprise at being single threaded. In the meantime setDTthreads(1) can be called manually before the explicit parallelism as a workaround. Matt On Tue, May 2, 2017 at 1:25 PM, Yan Alperovych <y_alperovych at yahoo.fr> wrote: > Dear Matt, > > I follow the Simon?s advice on this. Since R 3.4 the mclapply is producing > a strange error which...