similar to: accelerating matrix multiply

Hi Tomas, Can you share the full code for your benchmark, compiler options, and performance results so that I can try to reproduce them? There are a lot of variables that can affect the results. Private email is fine if it is too much for the mailing list. I am measuring on Knight's Landing (KNL) that was released in November. KNL is not a co-processor so no offload is necessary. R executes

>>>>> Cohn, Robert S <robert.s.cohn at intel.com> >>>>> on Sat, 7 Jan 2017 16:41:42 +0000 writes: > I am using R to multiply some large (30k x 30k double) > matrices on a 64 core machine (xeon phi). I added some timers > to src/main/array.c to see where the time is going. All of the > time is being spent in the matprod function, most of that

Hi Robert, thanks for the report and your suggestions how to make the NaN checks faster. Based on my experiments it seems that the "break" in the loop actually can have positive impact on performance even in the common case when we don't have NaNs. With gcc on linux (corei7), where isnan is inlined, the "break" version uses a conditional jump while the

> Do you have R code (including set.seed(.) if relevant) to show on how to generate > the large square matrices you've mentioned in the beginning? So we get to some > reproducible benchmarks? Hi Martin, Here is the program I used. I only generate 2 random numbers and reuse them to make the benchmark run faster. Let me know if there is something I can do to help--alternate

I am using R to multiply some large (30k x 30k double) matrices on a 64 core machine (xeon phi). I added some timers to src/main/array.c to see where the time is going. All of the time is being spent in the matprod function, most of that time is spent in dgemm. 15 seconds is in matprod in some code that is checking if there are NaNs. > system.time (C <- B %*% A) nancheck: wall time

Dmitriy Selivanov (selivanov.dmitriy at gmail.com) wrote: > Consider following example: > > a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1"))) > a[1, ] > # 1 > > It returns *unnamed* vector `1` where I would expect named vector. In fact > it returns named vector when number of columns is > 1. > Same issue applicable

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

On 14/07/2015 6:08 PM, Radford Neal wrote: > In testing pqR on Solaris SPARC systems, I have found two bugs that > are also present in recent R Core versions. You can see the bugs and > fixes at the following URLs: > > https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 Thanks for the report. Just one followup on this one: There are two sections

I have released a new, faster, version of R, which I call pqR (for "pretty quick" R), based on R-2.15.0. Among many other improvements, pqR supports automatic use of multiple cores to perform numerical computations in parallel with other numerical computations, and with the interpretive thread. It also implements a true reference counting scheme to reduce the amount of unnecessary

On Tue, Jul 14, 2015 at 07:52:56PM -0400, Duncan Murdoch wrote: > On 14/07/2015 6:08 PM, Radford Neal wrote: > > In testing pqR on Solaris SPARC systems, I have found two bugs that > > are also present in recent R Core versions. You can see the bugs and > > fixes at the following URLs: > > > >

> From: Philippe GROSJEAN <Philippe.GROSJEAN at umons.ac.be> > > ... for latest CRAN version, we have successfully installed 4999 > packages among the 5321 CRAN package on our platform. ... It is > strange that a large portion of R CMD check errors on CRAN occur and > disappear *without any version update* of a package or any of its > direct or indirect dependencies!

On Sun, 1 Mar 2015, Radford Neal wrote: > I think the discussion of this issue has gotten more complicated than > necessary. The discussion has gotten no more complicated than it needs to be. There are other instances, such as Reduce where there is a bug report pending that amounts to the same issue. Performing surgery on expressions and calling eval is not good practice at the R level

> Henrik Bengtsson: > > I'm looking for a way to get the length of an object 'x' as given by > base data type without dispatching on class. The performance improvement you're looking for is implemented in the latest version of pqR (pqR-2016-10-24, see pqR-project.org), along with corresponding improvements in several other circumstances where unclass(x) does not

> From: Tomas Kalibera <tomas.kalibera at gmail.com> > > Thanks for the report, I am working on a patch that will address this. > > I confirm there is a lot of potential for speedup. On my system, > > 'N=200000; x <- substring(paste(rep("A", N), collapse=""), 1:N, 1:N)' > > spends 96% time in checking if the string is ascii and 3%

> From: "Pavel S. Ruzankin" <ruzankin at math.nsc.ru> > Let us consider the current uniform sampling without replacement > algorithm. It resides in function do_sample in > https://svn.r-project.org/R/trunk/src/main/random.c > Its complexity is obviously O(n), where the sample is selected from > 1...n, since the algorithm has to create a vector of length n. So

I've looked at the code for matrix multiplies in R, and found that it can speeded up quite a bit, for multiplies that are really vector dot products, and for other multiplies in which the result matrix is small. Here's my test program: u <- seq(0,1,length=1000) v <- seq(0,2,length=1000) A2 <- matrix(2.1,2,1000) A5 <- matrix(2.1,5,1000) B3 <- matrix(3.2,1000,3) A4 <-

I think the discussion of this issue has gotten more complicated than necessary. First, there really is a bug. You can see this also by the fact that delayed warning messages are wrong. For instance, in R-3.1.2: > lapply(c(-1,2,-1),sqrt) [[1]] [1] NaN [[2]] [1] 1.414214 [[3]] [1] NaN Warning messages: 1: In FUN(c(-1, 2, -1)[[3L]], ...) : NaNs produced 2: In

Suharto, If you're interested in performance with subscripting, you might want to look at pqR (pqR-project.org). It has some substantial performance improvements for subscripting over R Core versions. This is especially true for the current development version of pqR (probably leading to a new release in about a month). You can look at a somewhat-stable snapshot of recent pqR development

Hi, I'm just following your messages the overhead that the code for dealing with possible NA/NaN values brings. When I was setting up part of the matrixStats package, I've also though about this. I was thinking of having an additional logical argument 'hasNA'/'has.na' where you as a user can specify whether there is NA/NaN:s or not, allowing the code to avoid it or not.

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