[Rd] configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]
On 10/31/23 10:45, Iñaki Ucar wrote:
On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera wrote:
The output of session info is based on that flexiblas is used and on
what flexiblas tells R is the backend it uses. R does not attempt to
check that optimized LAPACK functions from the backend really end up
called via flexiblas, and I don't think it could be realistically checked.
But I've checked one case manually in Fedora 38 using Linux perf tool.
The following code:
S <- toeplitz((10:1)/10)
repeat { R <- rWishart(10, 20, S) }
uses dpotrf from LAPACK, which is optimized in OpenBLAS and ATLAS and
the corresponding optimized implementations really appeared on the
sampling profile for me from the backend libraries.
The comment from R Admin has been removed now and if anyone runs into
the problem (that an optimized LAPACK function is not called from a
backend that provides it), it would be best to report it with sufficient
detail to flexiblas.
Thanks, Tomas. Yes, if an expected redirection to an optimized
function does not happen, that would be a bug in FlexiBLAS and should
be reported upstream.
Related to this, a small detail... I noticed that the R configure
script reports "BLAS(FlexiBlas)" correctly as an external library, but
then "LAPACK(generic)". This should be FlexiBLAS too instead of
"generic". It doesn't make any difference, since the LAPACK symbols in
FlexiBLAS are called anyway, but it's misleading.
This depends on how you configure R. On Fedora 38,
../trunk/configure --with-blas=flexiblas --with-lapack
reports "BLAS(FlexiBlas), LAPACK(in blas)" and from my reading of
R-admin, this is the recommended way of configuring with flexiblas.
Configuring via (is this what you had in mind?):
../trunk/configure --with-blas=flexiblas --with-lapack=flexiblas
reports "BLAS(FlexiBlas), LAPACK(generic)". The build would actually do
"-lflexiblas -lflexiblas", the former for LAPACK (from --with-lapack
value) and the latter for BLAS (from --with-blas value). The "generic"
here means not from BLAS, but from an extra standalone library. Compare
with the first (recommended) use when the build would only link
"-lflexiblas" once.
Best,
Tomas
Best,
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]
On Wed, 1 Nov 2023 at 12:57, Tomas Kalibera wrote:
>
>
> On 10/31/23 10:45, Iñaki Ucar wrote:
> > On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera
> > wrote:
> >> The output of session info is based on that flexiblas is used and on
> >> what flexiblas tells R is the backend it uses. R does not attempt to
> >> check that optimized LAPACK functions from the backend really end up
> >> called via flexiblas, and I don't think it could be realistically checked.
> >>
> >> But I've checked one case manually in Fedora 38 using Linux perf tool.
> >> The following code:
> >>
> >> S <- toeplitz((10:1)/10)
> >> repeat { R <- rWishart(10, 20, S) }
> >>
> >> uses dpotrf from LAPACK, which is optimized in OpenBLAS and ATLAS and
> >> the corresponding optimized implementations really appeared on the
> >> sampling profile for me from the backend libraries.
> >>
> >> The comment from R Admin has been removed now and if anyone runs into
> >> the problem (that an optimized LAPACK function is not called from a
> >> backend that provides it), it would be best to report it with sufficient
> >> detail to flexiblas.
> > Thanks, Tomas. Yes, if an expected redirection to an optimized
> > function does not happen, that would be a bug in FlexiBLAS and should
> > be reported upstream.
> >
> > Related to this, a small detail... I noticed that the R configure
> > script reports "BLAS(FlexiBlas)" correctly as an external library, but
> > then "LAPACK(generic)". This should be FlexiBLAS too instead of
> > "generic". It doesn't make any difference, since the LAPACK symbols in
> > FlexiBLAS are called anyway, but it's misleading.
>
> This depends on how you configure R. On Fedora 38,
>
> ../trunk/configure --with-blas=flexiblas --with-lapack
>
> reports "BLAS(FlexiBlas), LAPACK(in blas)" and from my reading of
> R-admin, this is the recommended way of configuring with flexiblas.
>
> Configuring via (is this what you had in mind?):
>
> ../trunk/configure --with-blas=flexiblas --with-lapack=flexiblas
>
> reports "BLAS(FlexiBlas), LAPACK(generic)". The build would actually do
> "-lflexiblas -lflexiblas", the former for LAPACK (from --with-lapack
> value) and the latter for BLAS (from --with-blas value). The "generic"
> here means not from BLAS, but from an extra standalone library. Compare
> with the first (recommended) use when the build would only link
> "-lflexiblas" once.
I see. I didn't understand that part then. I thought that a library
should be specified.
--
Iñaki Úcar
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)
> I assume it did, or you would not have noticed ?
I noticed it because I got a notice from CRAN about 'matrixStats'
starting to fail on R-devel. It was a non-critical failure, because
it was due to how the package tests compare the results to the
corresponding base-R implementation. Basically, for legacy reasons
there was a `dim(res) <- dim` statement and anything following assumed
the "dimnames" would be done. I've since rewritten the tests to not
make such assumptions, which resulted in code that is easier to
follow. So, there were good outcomes from this change too :)
The discussion on whether certain R expressions (e.g. dim(x) <-
dim(x)) should be no-op is interesting, but it's much bigger, and I
can see how it becomes a quite complicated discussion.
Thanks,
Henrik
On Mon, Oct 30, 2023 at 3:53 AM Martin Maechler
wrote:
>
>
> > Henrik Bengtsson
> > on Sun, 29 Oct 2023 10:42:19 -0700 writes:
>
> > Hello,
>
> > the fix of PR18612
> > (https://bugs.r-project.org/show_bug.cgi?id=18612) in
> > r85380
> >
> (https://github.com/wch/r-source/commit/2653cc6203fce4c48874111c75bbccac3ac4e803)
> > caused a change in `dim<-()`. Specifically, in the past,
> > any `dim<-()` assignment would _always_ remove "dimnames"
> > and "names" attributes per help("dim"):
>
>
> > The replacement method changes the "dim" attribute
> > (provided the new value is compatible) and removes any
> > "dimnames" and "names" attributes.
>
> > In the new version, assigning the same "dim" as before
> > will no longer remove "dimnames". I'm reporting here to
> > check whether this change was intended, or if it was an
> > unintended side effect of the bug fix.
>
> > For example, in R Under development (unstable) (2023-10-21
> > r85379), we would get:
>
> >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
> >> c("a","b"))) str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- dim(x) ## Removes "dimnames" no matter what
> >> str(dimnames(x))
> > NULL
>
>
> > whereas in R Under development (unstable) (2023-10-21
> > r85380) and beyond, we now get:
>
> >> x <- array(1:2, dim=c(1,2), dimnames=list("A",
> >> c("a","b"))) str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- dim(x) ## No longer removes "dimnames"
> >> str(dimnames(x))
> > List of 2 $ : chr "A" $ : chr [1:2] "a" "b"
>
> >> dim(x) <- rev(dim(x)) ## Still removes "dimnames"
> >> str(dimnames(x))
> > NULL
>
> > /Henrik
>
> Thank you, Henrik.
>
> This is "funny" (in an unusal sense):
> indeed, the change was *in*advertent, by me (svn rev 85380).
>
> I had experimentally {i.e., only in my own private version of R-devel!}
> modified the behavior of `dim<-` somewhat
> such it does *not* unnecessarily drop dimnames,
> e.g., in your `dim(x) <- dim(x)` case above,
> one could really argue that it's a "true loss" if x loses
> dimnames "unnecessarily" ...
>
> OTOH, I knew in the mean time that `dim<-` has always been
> documented to drop dimnames in all cases, and even more
> importantly, I got a strong recommendation to *not* go further
> with this idea -- not only for back compatibility reasons, but
> also for internal logical consistency.
>
> Most probably, we will just revert this inadvertent change,
> but before that ... since it has been out in the wild anyway,
> we could quickly consider if it *did* break code.
>
> I assume it did, or you would not have noticed ?
>
> Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]
On 11/1/23 13:29, Iñaki Ucar wrote:
On Wed, 1 Nov 2023 at 12:57, Tomas Kalibera wrote:
On 10/31/23 10:45, Iñaki Ucar wrote:
On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera wrote:
The output of session info is based on that flexiblas is used and on
what flexiblas tells R is the backend it uses. R does not attempt to
check that optimized LAPACK functions from the backend really end up
called via flexiblas, and I don't think it could be realistically checked.
But I've checked one case manually in Fedora 38 using Linux perf tool.
The following code:
S <- toeplitz((10:1)/10)
repeat { R <- rWishart(10, 20, S) }
uses dpotrf from LAPACK, which is optimized in OpenBLAS and ATLAS and
the corresponding optimized implementations really appeared on the
sampling profile for me from the backend libraries.
The comment from R Admin has been removed now and if anyone runs into
the problem (that an optimized LAPACK function is not called from a
backend that provides it), it would be best to report it with sufficient
detail to flexiblas.
Thanks, Tomas. Yes, if an expected redirection to an optimized
function does not happen, that would be a bug in FlexiBLAS and should
be reported upstream.
Related to this, a small detail... I noticed that the R configure
script reports "BLAS(FlexiBlas)" correctly as an external library, but
then "LAPACK(generic)". This should be FlexiBLAS too instead of
"generic". It doesn't make any difference, since the LAPACK symbols in
FlexiBLAS are called anyway, but it's misleading.
This depends on how you configure R. On Fedora 38,
../trunk/configure --with-blas=flexiblas --with-lapack
reports "BLAS(FlexiBlas), LAPACK(in blas)" and from my reading of
R-admin, this is the recommended way of configuring with flexiblas.
Configuring via (is this what you had in mind?):
../trunk/configure --with-blas=flexiblas --with-lapack=flexiblas
reports "BLAS(FlexiBlas), LAPACK(generic)". The build would actually do
"-lflexiblas -lflexiblas", the former for LAPACK (from --with-lapack
value) and the latter for BLAS (from --with-blas value). The "generic"
here means not from BLAS, but from an extra standalone library. Compare
with the first (recommended) use when the build would only link
"-lflexiblas" once.
I see. I didn't understand that part then. I thought that a library
should be specified.
I read this from R-Admin re --with-lapack:
"In practice its main uses are without a value,
- with an `enhanced' BLAS such as ATLAS, FlexiBLAS, MKL or OpenBLAS which
contains a full LAPACK (to avoid possible conflicts), or
- on Debian/Ubuntu systems to select the system liblapack which can
be switched by the `alternatives' mechanism.
"
I've updated configure in R-devel to detect when the same library is
specified explicitly for blas and lapack, so that now even that is
handled and reported as LAPACK in Blas libs.
Best
Tomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
