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