[Rd] blas test problem

[lejeczek]

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
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> -----------------------------------------------------------------------
> This message and its attachments are strictly confiden...{{dropped:9}}