[Rd] blas test problem

Fri Jul 11 10:08:26 CEST 2014

On 10/07/14 06:45, Prof Brian Ripley wrote:
> 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?
compared to "other" Rs on the same hardware platform(s) (AMD 
in each case)
a lot faster than "regular vanilla default" R that comes 
with all RHEL and derivatives
if Revo's R would be the one to match (it uses MKL and I 
imagine complied with Intel) then R+ACML is almost as fast, ~85%
Only fact spoils the satisfaction is that here with R ACML 
on AMD hardware is slower, even if only a bit than MKL, one 
would think AMD on AMD should be faster, but! at the same 
time bare in mind compiler whole tool chain and various 
optimisations - which turns out to be immensely important 
and I'm sure I have not gotten completely correct - I find 
that GNU compiler version 4.8.2 plus relevant toolchain that 
come with RHEL 7.0 sort of cripples R compilation with ACML 
(5.3.1, and 6.0 too) whereas gcc 4.7.2 (not available by 
default) on RHELs 6.5 gets me that ~85% of Revo's speed

there are other things (important too) to consider, TCO 
seems much better with ACML - I don't need to pay almost 1K 
Euros for Intel's libs (maybe + compiler suite costs) and 
naturally a lot more expensive Intel's CPUs, so I'm thinking 
if I can get it all working 100% only at %85 performance of 
MKL I would even go for AMD instead of Intel deliberately.

>
> 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
>
>