similar to: R 2.14.1 is released

A summary for reference: the new detectCores() for Windows in R-devel seems to be working both for logical and physical cores on systems with >64 logical processors? (thanks to Arun for testing!). If the feature is important for anyone particularly using an older version of Windows and/or on a system with >64 logical processors, it would be nice if you could test and report any

Hi, Both under the current R-devel (r66456) and a version from about 3 months ago, I experience the following behavior: > parallel::detectCores(TRUE) Error in system(cmd, TRUE) : error in running command > traceback() 3: system(cmd, TRUE) 2: gsub("^ +", "", system(cmd, TRUE)[1]) 1: parallel::detectCores(TRUE) > This is on Ubuntu 14.04. Does anybody else see this? [I

Dear Arun, thank you for checking the workaround scripts. I've modified detectCores() to use GetLogicalProcessorInformationEx. It is in revision 75198 of R-devel, could you please test it on your machines? For a binary, you can wait until the R-devel snapshot build gets to at least this svn revision. Thanks for the link to the processor groups documentation. I don't have a machine

Dear Arun, thank you for the report. I agree with the analysis, detectCores() will only report logical processors in the NUMA group in which R is running. I don't have a system to test on, could you please check these workarounds for me on your systems? # number of logical processors - what detectCores() should return out <- system("wmic cpu get numberoflogicalprocessors",

Dear Tomas, thank you very much. I installed r-devel r75201 and tested. The machine with 88 cores has NUMA disabled. It therefore has 2 processor groups with 64 and 24 processors each. require(parallel) detectCores() # [1] 88 This is great! Then I went on to test with a simple 'foreach()' loop. I started with 64 processors (max limit of 1 processor group). I ran with a simple function

Dear Tomas, thank you for looking into this. Here's the output: # number of logical processors - what detectCores() should return out <- system("wmic cpu get numberoflogicalprocessors", intern=TRUE) [1] "NumberOfLogicalProcessors \r" "22 \r" "22 \r" [4] "20 \r"

Dear R-devel list, R's detectCores() function internally calls "ncpus" function to get the total number of logical processors. However, this doesnot seem to take NUMA into account on Windows machines. On a machine having 48 processors (24 cores) in total and windows server 2012 installed, if NUMA is enabled and has 2 nodes (node 0 and node 1 each having 24 CPUs), then R's

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

In the 'parallel' package there is detectCores(), which tries its best to infer the number of cores on the current machine. This is useful if you wish to utilize the *maximum* number of cores on the machine. Several are using this to set the number of cores when parallelizing, sometimes also hardcoded within 3rd-party scripts/package code, but there are several settings where you wish to

R Version : 2.14.1 x64 Running on Windows 7 Connecting to a database on a remote Microsoft SQL Server 2012 The short form of my problem is the following. I have an unordered vectors of names, say: names<-c("A", "B", "A", "C","C") each of which have an id in a table in my db. I need to convert the names to their corresponding ids. I

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

Full_Name: Philip R. Kensche Version: 2.9.1 OS: Linux Submission from: (NULL) (131.174.146.252) Use case: Run R scripts using bin/Rscript or "bin/R --no-restore --file=<script-file> --args <args>" in a heterogeneous computing grid in which it is not possible to predict the actual installation directory of the R binaries. Problem: The script bin/R and the wrapper

On 18/11/17 18:18, Peter Langfelder wrote: > Rolf, > > looking at the configure script I believe you need to specify > > --with-tcl-config=/usr/lib/tcl8.6/tclConfig.sh > > and similarly > > --with-tk-config=<location of tkConfig.sh> > > HTH. Yes it helped. Thank you. I don't really understand why, but. I had previously (following an off-list

Hello, I was looking at the R (installed on RHEL6) shell script and saw R_HOME_DIR=/usr/lib64/R. Nowhere (and I could have got it wrong) does it read in the environment value R_HOME_DIR. I have the need to rsync the entire folder below /usr/lib64/R to another computer into another directory location. Without changing the R shell script, how can i force it read in R_HOME_DIR? Or maybe i

In R 3.3.2 detectCores() in package parallel reports 2 rather than 1 on Raspberry Pi B+ running Raspbian. (This report is just 'for the record'. The model is superseded and I think no longer produced.) The problem seems to be caused by grep processor /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) (On Raspberry Pi 2 and 3 there is no error because

Dirk may want to dig in here: Seems like you have a system with a /usr/lib64 dir for 64 bit libraries, but Tcl files in /usr/lib. If that is not an anomaly, it looks like we have a configure bug (conceiveably, a system might be using /usr/lib for architecture-independent files, and lib64/lib32 for binaries). It doesn't look too hard to modify configure to also check /usr/lib, but we probably

Hum, missed that bit. Looking at the configure script, the only way I can see it failing to look in /usr/lib/tcl8.6 is if ${LIBnn} is not "lib". Any chance it might be set to lib64? -pd > On 18 Nov 2017, at 22:32 , Rolf Turner <r.turner at auckland.ac.nz> wrote: > > > On 19/11/17 05:36, Albrecht Kauffmann wrote: > >> Did you istall the tcl- and tk-devel

Dear expeRts, I struggle with the following problem using snow clusters for parallel computing: I would like to specify l'Ecuyer's random number generator. Base R creates a .Random.seed of length 7, the first value indicating the kind fo random number generator. I would thus like to use the components 2 to 7 as the seed for l'Ecuyer's random number generator. By doing so, I

On Fri, Jan 10, 2020 at 11:23 AM Simon Urbanek <simon.urbanek at r-project.org> wrote: > > Henrik, > > the example from the post works just fine in CRAN R for me - the post was about homebrew build so it's conceivably a bug in their libraries. Thanks for ruling that example out. > That's exactly why I was proposing a more general solution where you can simply define

I've started to use the parallel package and it works very well speeding things up. Thank you for making this easy to do. Should I have expected that parCapply would return a vector when parApply returns a matrix? library(parallel) x <- matrix(rnorm(8), nc = 2) apply(x, 2, function(y) y) [,1] [,2] [1,] -0.9649685 0.91339851 [2,] -1.4313140 0.13457671 [3,] 1.0499248