[Rd] blas test problem

[Prof Brian Ripley]

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
>>>>>
>>>>> ______________________________________________
>>>>> 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}}
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595