R devel - Nov 2023 - configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]

On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera <tomas.kalibera at gmail.com>
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.

Best,
-- 
I?aki ?car

On 10/31/23 10:45, I?aki Ucar wrote:
> On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera <tomas.kalibera at
gmail.com> 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,