similar to: Another issue using multi-processing linear algebra libraries

I also have this questions for this. I wonder if R initiates a system environment or options to instruct the packages on the number of cores to use? It doesn't have to be mandatory for now, but at least package maintainers can have shared consensus and start to adopt this humble settings rather than abusing parallel::detectCores() to max out the number of threads by default. > On Aug 7,

> "There?s a downside not mentioned in the manual that caught and baffled me for a while. I was using all 64 cores of an AWS instance via parallel::mclapply() and doing matrix multiplications in the parallelized function. If the matrices were big enough the linked BLAS or LAPACK would try to use all 64 cores for each multiplication, which meant 64^2 processes or threads in some combination

I agree that the "R Installation and Administration" guide statement about FlexiBLAS needs an update. Standard R in CentOS Stream 9, which is now downstream from Fedora, gives the following result for Matrix products in sessionInfo(): > sessionInfo() R version 4.3.1 (2023-06-16) Platform: x86_64-redhat-linux-gnu (64-bit) Running under: CentOS Stream 9 Matrix products: default

Dear R wizards--- I have a wrapper on mclapply() that makes it a little easier for me to do multiprocessing. (Posting this may make life easier for other googlers.) I pass a data frame, a vector that tells me what rows should be recomputed, and the function; and I get back a vector or matrix of answers. d <- data.frame( id=1:6, val=11:16 ) loc <- c(TRUE,TRUE,FALSE,TRUE,FALSE,TRUE)

On 10/11/23 23:12, George Ostrouchov wrote: > I agree that the "R Installation and Administration" guide statement about FlexiBLAS needs an update. Standard R in CentOS Stream 9, which is now downstream from Fedora, gives the following result for Matrix products in sessionInfo(): > >> sessionInfo() > R version 4.3.1 (2023-06-16) > Platform: x86_64-redhat-linux-gnu

On 21/03/2005, at 10:09 PM, David Firth wrote: > I am sorry that I wasn't clear. All that I meant was that *this* > problem can result in different behaviour in "ordinary" statistical > applications. For example, if the objective function in a call to > optim() involves calling one of these linear algebra routines, the > result may be NaN (on systems other than Mac

Hi Ista, Maybe a little comment in the 'matmult {base}' doc page or on the 'options {base}' in the field 'matprod' would be useful to remind users to be cautious regarding BLAS multi-threading? I understand why this is a BLAS related issue and not directly an R related issue. Nonetheless, my concern was for non-advanced R users, that may don't even know what BLAS

No, blas/veclib is tested, so aprt this extreme case you should report some other more commonly used cases in which something fails on OS X. This will help us to work it out. As said, I'll try some tests without using veclib and let you know. I've fowarded this mail to r-devel, which seems to be the right place, so for future msg on the subject please use r-devel. stefano On

Dear Miguel Esteva, I couldn't get a Red Hat "ubi9" container to install enough dependencies to build R. Is there a way to reproduce your setup on a virtual machine somewhere? On Fri, 3 May 2024 00:42:43 +0000 Miguel Esteva via R-help <r-help at r-project.org> wrote: > *** caught segfault *** > > address 0x1801fa8f70, cause 'memory not mapped' > >

Hi Ghislain, I think you might be comparing two versions of R with different BLAS implementations, one that is single threaded (is your 3.3.2 used with reference blas?) and one that is multi threaded (3.4.1 with openblas). Could you check with "perf"? E.g. run your benchmark with "perf record" in both cases and you should see the names of the hot BLAS functions and this

OK, I give up and come grovelling, "Fork" was suggested at 18:23, it's now 22:20 and I have been through 4 different methods, all block with a 2 second delay before returning to dialplan. Here are just some of the examples I have tried, as as per the suggestions, I am closing all possible outputs in the forked process. https://docs.python.org/3.5/library/multiprocessing.html

Greetings: We are evaluating the performance of R matrix algebra es as we port a MATLAB R14 script into R. The MATLAB code basically evaluates the AX=B system on sparse matrices that result in output matrices of 100 to 1,000,000 rows/columns. Our R prototype script uses spase base matrices and the methods qr() and qr.coeff(). The following statements are called inside a doubly-nested loop: G

Seems like this in 83986 [1] needs a fix in Lapack.c: if (dladdr((void *) F77_NAME(ilaver), &dl_info)) { char buf[PATH_MAX+1]; char *res = realpath(dl_info.dli_fname, buf); if (res) { SEXP nfo = R_NilValue; if (strstr(res, "flexiblas")) nfo = R_flexiblas_info(); if

Hi Ghislain, The documentation at https://cran.r-project.org/doc/manuals/r-release/R-admin.html#BLAS provides a fair bit of information. What specifically would you like to see added? Best, Ista On Mon, Aug 21, 2017 at 10:13 AM, Ghislain Durif <ghislain.durif at inria.fr> wrote: > Hi Tomas, > > Thanks for your answer. > > Indeed, I checked and my R-3.4.1 installed from the

Hi Ivan, An apology, I was away for quite a bit. To reproduce the setup: I have been using the default GCC in RHEL 9.1. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-host-pie

In the root llvm/CMakeLists.txt we have: if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 ) message(FATAL_ERROR "Python 2.7 or newer is required") endif() But lit seems to still be stuck in a Python 2.5 world. For example, detectCPUs is redundant now that we have multiprocessing.cpu_count() (multiprocessing requires >=2.6). And there are a bunch of other Python 2.5 workarounds

Hi Tomas, Thanks for your answer. Indeed, I checked and my R-3.4.1 installed from the ubuntu repository use 'libopenblasp-r0.2.18.so' while my R-3.3.2 that I did compiled on my machine use 'libRblas.so' which explain the difference of behavior. I will use RhpcBLASctl to avoid issue when combining matrix product and other multi-threading package. Maybe this point regarding

Hi, I have installed Calibre using wine 1.3.22 . The program is not usable since adding/converting ebooks is not working. Running wine calibre-debug -g I get the following error: Exception in thread Thread-4: Traceback (most recent call last): File "threading.py", line 530, in __bootstrap_inner File "site-packages\calibre\utils\ipc\server.py", line 221, in run File

On Fri, 2016-01-15 at 15:03 +0100, Daniel Kaschek wrote: > Dear all, > > I run different R versions (3.2.1, 3.2.2 and 3.2.3) on different > platforms (Arch, Ubuntu, Debian) with a different number of available > cores (24, 4, 24). The following line produces very different behavior > on the three machines: > > for(i in 1:1e6) {n <- 100; M <- matrix(rnorm(n^2), n,

Dear R Core Team, I wish to report what can be viewed as a bug or at least a strange behavior in R-3.4.1. I ask my question here (as recommended on https://www.r-project.org/bugs.html) since I am not member of the R's Bugzilla. When running 'R --vanilla' from the command line, the standard matrix product is by default based on BLAS and multi-threaded on all cores available on