blas test problem

later I tried plain-vanilla, well.. redhats' and derivatives 
default packages and they all fail:

 > ## PR#4582 %*% with NAs
 > stopifnot(is.na(NA %*% 0), is.na(0 %*% NA))
 > ## depended on the BLAS in use.
 >
 >
 > ## found from fallback test in slam 0.1-15
 > ## most likely indicates an inaedquate BLAS.
 > x <- matrix(c(1, 0, NA, 1), 2, 2)
 > y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2)
 > (z <- tcrossprod(x, y))

      [,1] [,2] [,3]
[1,]   NA   NA    0
[2,]    2    1    0

 > stopifnot(identical(z, x %*% t(y)))

Error: identical(z, x %*% t(y)) is not TRUE
Execution halted


I've tried scientificLinux, Centos, Oracle
all versions of R => 3.0 these linux distribution provide
hardware are AMD various CPU based platform


On 30/06/14 10:45, peter dalgaard wrote:

It is not clear what you mean:

The quoted page lists particular AMD BLAS versions that fail R's regression test.

Other builds of R would run the regression test during building and you can run them yourself if you get the source code (for good measure, use the current version, not one from a 2011 web posting, i.e., fetch say https://svn.r-project.org/R/branches/R-3-1-branch/tests/reg-BLAS.R).

E.g., for me

Peters-iMac:R pd$ ../BUILD/bin/R --vanilla < tests/reg-BLAS.R
... normal output, no errors ...

There is some risk that binary builds of R on one machine will fail on another. If this happens, it could be quite serious, so developers would want to know. However "most...seem to fail" is not enough to act upon. What exactly did you do, on which computing platform, and what happened that makes you believe that it had failed?

-pd

On 27 Jun 2014, at 13:38 , lejeczek <peljasz at yahoo.co.uk> wrote:

dear developers

I myself am not a prog-devel, I found this

http://devgurus.amd.com/message/1255852#1255852

Most R compilations/installations I use seem to fail this test, is this a problem and if yes then how serious is it?

regards

I can reproduce this. It is a bug in reference BLAS.

With the R 3.1.0 release, Fedora changed from using the internal BLAS
that comes with R to using external BLAS. But reference BLAS does not
handle missing values correctly.  I expect this has been true since at
least 2010, when Brian patched the R copy of BLAS, but the bug has only
been revealed by the Fedora policy change.

I am taking this over to R-SIG-Fedora where we can discuss the issue
with Tom Callaway from Red Hat.

Martyn

On Fri, 2014-07-04 at 12:13 +0100, lejeczek wrote:

later I tried plain-vanilla, well.. redhats' and derivatives
default packages and they all fail:

  > ## PR#4582 %*% with NAs
  > stopifnot(is.na(NA %*% 0), is.na(0 %*% NA))
  > ## depended on the BLAS in use.
  >
  >
  > ## found from fallback test in slam 0.1-15
  > ## most likely indicates an inaedquate BLAS.
  > x <- matrix(c(1, 0, NA, 1), 2, 2)
  > y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2)
  > (z <- tcrossprod(x, y))

       [,1] [,2] [,3]
[1,]   NA   NA    0
[2,]    2    1    0

  > stopifnot(identical(z, x %*% t(y)))

Error: identical(z, x %*% t(y)) is not TRUE
Execution halted


I've tried scientificLinux, Centos, Oracle
all versions of R => 3.0 these linux distribution provide
hardware are AMD various CPU based platform


On 30/06/14 10:45, peter dalgaard wrote:

It is not clear what you mean:

The quoted page lists particular AMD BLAS versions that fail R's regression test.

Other builds of R would run the regression test during building and you can run them yourself if you get the source code (for good measure, use the current version, not one from a 2011 web posting, i.e., fetch say https://svn.r-project.org/R/branches/R-3-1-branch/tests/reg-BLAS.R).

E.g., for me

Peters-iMac:R pd$ ../BUILD/bin/R --vanilla < tests/reg-BLAS.R
... normal output, no errors ...

There is some risk that binary builds of R on one machine will fail on another. If this happens, it could be quite serious, so developers would want to know. However "most...seem to fail" is not enough to act upon. What exactly did you do, on which computing platform, and what happened that makes you believe that it had failed?

-pd

On 27 Jun 2014, at 13:38 , lejeczek <peljasz at yahoo.co.uk> wrote:

dear developers

I myself am not a prog-devel, I found this

http://devgurus.amd.com/message/1255852#1255852

Most R compilations/installations I use seem to fail this test, is this a problem and if yes then how serious is it?

regards

-----------------------------------------------------------------------
This message and its attachments are strictly confiden...{{dropped:9}}

I wonder if anyone amongst developers had a chance to try ACML.

AMD's implementation when R is supposed to use it seems to fail the test
similarly,

on a side note, I had R build with ACML and performance-wise it looked
really really promising,

however now http://r.research.att.com/benchmarks/R-benchmark-25.R
gets me far! worse results, it sort of chokes up on FFT part, takes much
longer than "regular" R, takes ages.
I see all: ./lib64/R/lib/libR.so ./lib64/R/lib/libRblas.so
./lib64/R/lib/libRlapack.so depend on libacml_mp.so
I've tried few different ACML versions, I wonder could it be R => 3.0
itself?
and thoughts on why it is so under performing?


On 07/07/14 13:14, Martyn Plummer wrote:

I can reproduce this. It is a bug in reference BLAS.

With the R 3.1.0 release, Fedora changed from using the internal BLAS
that comes with R to using external BLAS. But reference BLAS does not
handle missing values correctly.  I expect this has been true since at
least 2010, when Brian patched the R copy of BLAS, but the bug has only
been revealed by the Fedora policy change.

I am taking this over to R-SIG-Fedora where we can discuss the issue
with Tom Callaway from Red Hat.

Martyn

On Fri, 2014-07-04 at 12:13 +0100, lejeczek wrote:

later I tried plain-vanilla, well.. redhats' and derivatives
default packages and they all fail:

  > ## PR#4582 %*% with NAs
  > stopifnot(is.na(NA %*% 0), is.na(0 %*% NA))
  > ## depended on the BLAS in use.
  >
  >
  > ## found from fallback test in slam 0.1-15
  > ## most likely indicates an inaedquate BLAS.
  > x <- matrix(c(1, 0, NA, 1), 2, 2)
  > y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2)
  > (z <- tcrossprod(x, y))

       [,1] [,2] [,3]
[1,]   NA   NA    0
[2,]    2    1    0

  > stopifnot(identical(z, x %*% t(y)))

Error: identical(z, x %*% t(y)) is not TRUE
Execution halted


I've tried scientificLinux, Centos, Oracle
all versions of R => 3.0 these linux distribution provide
hardware are AMD various CPU based platform


On 30/06/14 10:45, peter dalgaard wrote:

It is not clear what you mean:

The quoted page lists particular AMD BLAS versions that fail R's
regression test.

Other builds of R would run the regression test during building and
you can run them yourself if you get the source code (for good
measure, use the current version, not one from a 2011 web posting,
i.e., fetch say
https://svn.r-project.org/R/branches/R-3-1-branch/tests/reg-BLAS.R).

E.g., for me

Peters-iMac:R pd$ ../BUILD/bin/R --vanilla < tests/reg-BLAS.R
... normal output, no errors ...

There is some risk that binary builds of R on one machine will fail
on another. If this happens, it could be quite serious, so
developers would want to know. However "most...seem to fail" is not
enough to act upon. What exactly did you do, on which computing
platform, and what happened that makes you believe that it had failed?

-pd

On 27 Jun 2014, at 13:38 , lejeczek <peljasz at yahoo.co.uk> wrote:

dear developers

I myself am not a prog-devel, I found this

http://devgurus.amd.com/message/1255852#1255852

Most R compilations/installations I use seem to fail this test, is
this a problem and if yes then how serious is it?

regards

-----------------------------------------------------------------------
This message and its attachments are strictly confiden...{{dropped:9}}

On 09/07/2014 17:17, lejeczek wrote:

I wonder if anyone amongst developers had a chance to try 
ACML.

Yes, and documented its use in the R manual over many years.

AMD's implementation when R is supposed to use it seems 
to fail the test
similarly,

Please do read the manual for yourself (see the posting 
guide): 
http://cran.r-project.org/doc/manuals/r-patched/R-admin.html#ACML 
.

on a side note, I had R build with ACML and 
performance-wise it looked
really really promising,

Compared to what and on what CPU?

I have found ACML disappointing compared to MKL or even 
ATLAS on the CPUs I use (which are Intel, but then most 
people's are).

however now 
http://r.research.att.com/benchmarks/R-benchmark-25.R
gets me far! worse results, it sort of chokes up on FFT 
part, takes much
longer than "regular" R, takes ages.
I see all: ./lib64/R/lib/libR.so ./lib64/R/lib/libRblas.so
./lib64/R/lib/libRlapack.so depend on libacml_mp.so
I've tried few different ACML versions, I wonder could it 
be R => 3.0
itself?
and thoughts on why it is so under performing?


On 07/07/14 13:14, Martyn Plummer wrote:

I can reproduce this. It is a bug in reference BLAS.

With the R 3.1.0 release, Fedora changed from using the 
internal BLAS
that comes with R to using external BLAS. But reference 
BLAS does not
handle missing values correctly.  I expect this has been 
true since at
least 2010, when Brian patched the R copy of BLAS, but 
the bug has only
been revealed by the Fedora policy change.

I am taking this over to R-SIG-Fedora where we can 
discuss the issue
with Tom Callaway from Red Hat.

Martyn

On Fri, 2014-07-04 at 12:13 +0100, lejeczek wrote:

later I tried plain-vanilla, well.. redhats' and 
derivatives
default packages and they all fail:

  > ## PR#4582 %*% with NAs
  > stopifnot(is.na(NA %*% 0), is.na(0 %*% NA))
  > ## depended on the BLAS in use.
  >
  >
  > ## found from fallback test in slam 0.1-15
  > ## most likely indicates an inaedquate BLAS.
  > x <- matrix(c(1, 0, NA, 1), 2, 2)
  > y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2)
  > (z <- tcrossprod(x, y))

       [,1] [,2] [,3]
[1,]   NA   NA    0
[2,]    2    1    0

  > stopifnot(identical(z, x %*% t(y)))

Error: identical(z, x %*% t(y)) is not TRUE
Execution halted


I've tried scientificLinux, Centos, Oracle
all versions of R => 3.0 these linux distribution provide
hardware are AMD various CPU based platform


On 30/06/14 10:45, peter dalgaard wrote:

It is not clear what you mean:

The quoted page lists particular AMD BLAS versions 
that fail R's
regression test.

Other builds of R would run the regression test during 
building and
you can run them yourself if you get the source code 
(for good
measure, use the current version, not one from a 2011 
web posting,
i.e., fetch say
https://svn.r-project.org/R/branches/R-3-1-branch/tests/reg-BLAS.R). 


E.g., for me

Peters-iMac:R pd$ ../BUILD/bin/R --vanilla < 
tests/reg-BLAS.R
... normal output, no errors ...

There is some risk that binary builds of R on one 
machine will fail
on another. If this happens, it could be quite 
serious, so
developers would want to know. However "most...seem to 
fail" is not
enough to act upon. What exactly did you do, on which 
computing
platform, and what happened that makes you believe 
that it had failed?

-pd

On 27 Jun 2014, at 13:38 , lejeczek 
<peljasz at yahoo.co.uk> wrote:

dear developers

I myself am not a prog-devel, I found this

http://devgurus.amd.com/message/1255852#1255852

Most R compilations/installations I use seem to fail 
this test, is
this a problem and if yes then how serious is it?

regards

----------------------------------------------------------------------- 

This message and its attachments are strictly 
confiden...{{dropped:9}}