OpenBLAS in everyday R?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenBLAS in everyday R?

Kenny Bell-2
Hi R-devel list,

OpenBLAS is readily available for unix-likes:

https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf

However, my questions are:

1) Would R-devel consider using OpenBLAS for the main distribution of R for
all platforms including Windows?
2) If so, would R-devel set the default multi-thread level to the number of
(real) cores on a machine?

My sense is there're a lot of wasted resources on laptops and personal
desktops around the world that could be utilised by such a switch. I
believe most unix-like users don't know about OpenBLAS and are blissfully
ignorant of the available speed gains. It seems to be quite difficult for a
typical Windows user to get this done today.

Thanks heaps,
Kenny

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Dirk Eddelbuettel

Kenny,

On 17 December 2017 at 09:28, Kenny Bell wrote:
| Hi R-devel list,
|
| OpenBLAS is readily available for unix-likes:
|
| https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf

Please consider re-reading this vignette of mine. BLAS is an interface,
OpenBLAS is but one implementation.  R has allowed you to switch between
different implementations for a long time (if you used a shared library
build), and illustrating / measuring the possible performance differences is
the whole point of the gcbd benchmarking package.
 
| However, my questions are:
|
| 1) Would R-devel consider using OpenBLAS for the main distribution of R for
| all platforms including Windows?
| 2) If so, would R-devel set the default multi-thread level to the number of
| (real) cores on a machine?

It's complicated. If you fork at the process-level (with package parallel or
one of the many other mechansim) and then also used multi-threaded BLAS you
can starve yourself for resources quickly.
 
| My sense is there're a lot of wasted resources on laptops and personal
| desktops around the world that could be utilised by such a switch. I
| believe most unix-like users don't know about OpenBLAS and are blissfully
| ignorant of the available speed gains. It seems to be quite difficult for a
| typical Windows user to get this done today.

Many things a developer / power-user would do are very difficult on
Windows. It is one of the charms of the platform. On the other hand you do
get a few solitaire games so I guess everybody is happy.

Dirk
 
| Thanks heaps,
| Kenny
|
| [[alternative HTML version deleted]]
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Keith O'Hara
On point 1):

The standard approach seems to favor the reference BLAS for reasons other
than speed.

For example, vecLib, Apple's multi-threaded BLAS library, is not the
default choice for macOS binaries due to concerns about 'precision'. See:

https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic
h-BLAS-is-used-and-how-can-it-be-changed_003f

This doesn't appear to be Mac- or vecLib-specifc. R-Core seem wary of
non-reference BLAS implementations for several reasons:

'External BLAS implementations often make less use of extended-precision
floating-point registers and will almost certainly re-order computations.
This can result in less accuracy than using the internal BLAS, and may
result in different solutions, e.g. different signs in SVD and
eigendecompositions.'

https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#BLAS

I'm not sure how pervasive a problem this is, though.

Keith


On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel <[hidden email]> wrote:

>
> Kenny,
>
> On 17 December 2017 at 09:28, Kenny Bell wrote:
> | Hi R-devel list,
> |
> | OpenBLAS is readily available for unix-likes:
> |
> | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
>
> Please consider re-reading this vignette of mine. BLAS is an interface,
> OpenBLAS is but one implementation.  R has allowed you to switch between
> different implementations for a long time (if you used a shared library
> build), and illustrating / measuring the possible performance differences
> is
> the whole point of the gcbd benchmarking package.
>
> | However, my questions are:
> |
> | 1) Would R-devel consider using OpenBLAS for the main distribution of R
> for
> | all platforms including Windows?
> | 2) If so, would R-devel set the default multi-thread level to the number
> of
> | (real) cores on a machine?
>
> It's complicated. If you fork at the process-level (with package parallel
> or
> one of the many other mechansim) and then also used multi-threaded BLAS you
> can starve yourself for resources quickly.
>
> | My sense is there're a lot of wasted resources on laptops and personal
> | desktops around the world that could be utilised by such a switch. I
> | believe most unix-like users don't know about OpenBLAS and are blissfully
> | ignorant of the available speed gains. It seems to be quite difficult
> for a
> | typical Windows user to get this done today.
>
> Many things a developer / power-user would do are very difficult on
> Windows. It is one of the charms of the platform. On the other hand you do
> get a few solitaire games so I guess everybody is happy.
>
> Dirk
>
> | Thanks heaps,
> | Kenny
> |
> |       [[alternative HTML version deleted]]
> |
> | ______________________________________________
> | [hidden email] mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Kenny Bell-2
In reply to this post by Kenny Bell-2
On Sun, Dec 17, 2017 at 10:01 AM, Dirk Eddelbuettel <[hidden email]> wrote:

>
> Kenny,
>
> On 17 December 2017 at 09:28, Kenny Bell wrote:
> | Hi R-devel list,
> |
> | OpenBLAS is readily available for unix-likes:
> |
> | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
>
> Please consider re-reading this vignette of mine. BLAS is an interface,
> OpenBLAS is but one implementation.  R has allowed you to switch between
> different implementations for a long time (if you used a shared library
> build), and illustrating / measuring the possible performance differences
> is
> the whole point of the gcbd benchmarking package.
>

Understood. To be clear, my suggestion is to change the *default* BLAS
implementation to multithreaded OpenBLAS.


> | However, my questions are:
> |
> | 1) Would R-devel consider using OpenBLAS for the main distribution of R
> for
> | all platforms including Windows?
> | 2) If so, would R-devel set the default multi-thread level to the number
> of
> | (real) cores on a machine?
>
> It's complicated. If you fork at the process-level (with package parallel
> or
> one of the many other mechansim) and then also used multi-threaded BLAS you
> can starve yourself for resources quickly.
>
>
This indeed was my experience if not being careful when using MRO, which
also has a multithreaded algebra library as the default. However, the
overall speed benefits far outweighed the costs. MRO helped to overcome
this problem with an interface to change the number of threads to use. In
MRO, it is on the user to switch this before using any explicit parallel
functionality. Another question, does using multithreaded OpenBLAS mess
with RcppParallel?


> | My sense is there're a lot of wasted resources on laptops and personal
> | desktops around the world that could be utilised by such a switch. I
> | believe most unix-like users don't know about OpenBLAS and are blissfully
> | ignorant of the available speed gains. It seems to be quite difficult
> for a
> | typical Windows user to get this done today.
>
> Many things a developer / power-user would do are very difficult on
> Windows. It is one of the charms of the platform. On the other hand you do
> get a few solitaire games so I guess everybody is happy.
>
> Dirk
>
> | Thanks heaps,
> | Kenny
> |
> |       [[alternative HTML version deleted]]
> |
> | ______________________________________________
> | [hidden email] mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Kenny Bell-2
In reply to this post by Keith O'Hara
It seems that reproducibility across systems is also an issue with
multithreaded BLASes:

https://hal.archives-ouvertes.fr/hal-01202396/file/exblas.pdf

On Sun, Dec 17, 2017 at 11:50 AM, Keith O'Hara <[hidden email]> wrote:

> On point 1):
>
> The standard approach seems to favor the reference BLAS for reasons other
> than speed.
>
> For example, vecLib, Apple's multi-threaded BLAS library, is not the
> default choice for macOS binaries due to concerns about 'precision'. See:
>
> https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic
> h-BLAS-is-used-and-how-can-it-be-changed_003f
>
> This doesn't appear to be Mac- or vecLib-specifc. R-Core seem wary of
> non-reference BLAS implementations for several reasons:
>
> 'External BLAS implementations often make less use of extended-precision
> floating-point registers and will almost certainly re-order computations.
> This can result in less accuracy than using the internal BLAS, and may
> result in different solutions, e.g. different signs in SVD and
> eigendecompositions.'
>
> https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#BLAS
>
> I'm not sure how pervasive a problem this is, though.
>
> Keith
>
>
> On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel <[hidden email]> wrote:
>
>>
>> Kenny,
>>
>> On 17 December 2017 at 09:28, Kenny Bell wrote:
>> | Hi R-devel list,
>> |
>> | OpenBLAS is readily available for unix-likes:
>> |
>> | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
>>
>> Please consider re-reading this vignette of mine. BLAS is an interface,
>> OpenBLAS is but one implementation.  R has allowed you to switch between
>> different implementations for a long time (if you used a shared library
>> build), and illustrating / measuring the possible performance differences
>> is
>> the whole point of the gcbd benchmarking package.
>>
>> | However, my questions are:
>> |
>> | 1) Would R-devel consider using OpenBLAS for the main distribution of R
>> for
>> | all platforms including Windows?
>> | 2) If so, would R-devel set the default multi-thread level to the
>> number of
>> | (real) cores on a machine?
>>
>> It's complicated. If you fork at the process-level (with package parallel
>> or
>> one of the many other mechansim) and then also used multi-threaded BLAS
>> you
>> can starve yourself for resources quickly.
>>
>> | My sense is there're a lot of wasted resources on laptops and personal
>> | desktops around the world that could be utilised by such a switch. I
>> | believe most unix-like users don't know about OpenBLAS and are
>> blissfully
>> | ignorant of the available speed gains. It seems to be quite difficult
>> for a
>> | typical Windows user to get this done today.
>>
>> Many things a developer / power-user would do are very difficult on
>> Windows. It is one of the charms of the platform. On the other hand you do
>> get a few solitaire games so I guess everybody is happy.
>>
>> Dirk
>>
>> | Thanks heaps,
>> | Kenny
>> |
>> |       [[alternative HTML version deleted]]
>> |
>> | ______________________________________________
>> | [hidden email] mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Juan Telleria
Multi-threaded Math Libraries (Trough OpenBlas), taking into account that
today's laptops have a minimum of 2-4 cores, are an important topic, and in
my opinion, shall be included in R for the general interest.

I think that the way to go would be to create a configuration setting in
R's options(OpenBlas= TRUE|FALSE) which enables or disables OpenBlas in an
easy way, which by default shall be in FALSE (In order to avoid issues with
parallel libraries).

The key point would be that each time you open a new R session, a 1 liner
informative comment arises that tells you:
a) Whether OpenBlas is enabled or disabled.
b) And how many cores it uses (Setting also configurable through
options(...))

In a shape just as Microsoft R Open does.

Kind regards,
Juan Telleria

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Juan Telleria
Multi-threaded Math Libraries (Trough OpenBlas), taking into account that
today's laptops have a minimum of 2-4 cores, are an important topic, and in
my opinion, shall be included in R for the general interest.

I think that the way to go would be to create a configuration setting in
R's options(OpenBlas=TRUE|FALSE) which enables or disables OpenBlas in an
easy way, which by default shall be in FALSE (In order to avoid issues with
parallel libraries).

The key point would be that each time you open a new R session, a 1 liner
informative comment arises that tells you:

a) Whether OpenBlas is enabled or disabled.

b) And how many cores it uses (Setting also configurable through
options(...))

In a shape just as Microsoft R Open does.

Kind regards,
Juan Telleria


El 17/12/2017 12:31 a. m., "Juan Telleria" <[hidden email]> escribió:

> Multi-threaded Math Libraries (Trough OpenBlas), taking into account that
> today's laptops have a minimum of 2-4 cores, are an important topic, and in
> my opinion, shall be included in R for the general interest.
>
> I think that the way to go would be to create a configuration setting in
> R's options(OpenBlas= TRUE|FALSE) which enables or disables OpenBlas in an
> easy way, which by default shall be in FALSE (In order to avoid issues with
> parallel libraries).
>
> The key point would be that each time you open a new R session, a 1 liner
> informative comment arises that tells you:
> a) Whether OpenBlas is enabled or disabled.
> b) And how many cores it uses (Setting also configurable through
> options(...))
>
> In a shape just as Microsoft R Open does.
>
> Kind regards,
> Juan Telleria
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

plangfelder
In reply to this post by Kenny Bell-2
I would be very cautious about OpenBLAS in particular...  from time to
time I get complains from users that compiled code calculations in my
WGCNA package crash or produce wrong answers with large data, and they
all come from OpenBLAS users. I am yet to reproduce any of their
crashes when using MKL and ATLAS BLAS implementations.

Just my 2 cents...

Peter

On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell <[hidden email]> wrote:

> Hi R-devel list,
>
> OpenBLAS is readily available for unix-likes:
>
> https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
>
> However, my questions are:
>
> 1) Would R-devel consider using OpenBLAS for the main distribution of R for
> all platforms including Windows?
> 2) If so, would R-devel set the default multi-thread level to the number of
> (real) cores on a machine?
>
> My sense is there're a lot of wasted resources on laptops and personal
> desktops around the world that could be utilised by such a switch. I
> believe most unix-like users don't know about OpenBLAS and are blissfully
> ignorant of the available speed gains. It seems to be quite difficult for a
> typical Windows user to get this done today.
>
> Thanks heaps,
> Kenny
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Kenny Bell-2
It seems like many of the multi-threaded BLASes have some sort of
fundamental problem preventing use in the way Juan suggests:

 - Dirk's vignette states that ATLAS "fixes the number of cores used at
compile-time and cannot vary this setting at run-time", so any
user-friendly implementation for R would have to compile ATLAS for 1-16
threads to allow the user to switch at run-time. This might dramatically
affect install times.

 - MKL seems like it's been outright rejected in the past based on not
being "free-enough".

 - OpenBLAS causes crashes.

Has anyone tried ExBLAS for use with R?

On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder <
[hidden email]> wrote:

> I would be very cautious about OpenBLAS in particular...  from time to
> time I get complains from users that compiled code calculations in my
> WGCNA package crash or produce wrong answers with large data, and they
> all come from OpenBLAS users. I am yet to reproduce any of their
> crashes when using MKL and ATLAS BLAS implementations.
>
> Just my 2 cents...
>
> Peter
>
> On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell <[hidden email]> wrote:
> > Hi R-devel list,
> >
> > OpenBLAS is readily available for unix-likes:
> >
> > https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
> >
> > However, my questions are:
> >
> > 1) Would R-devel consider using OpenBLAS for the main distribution of R
> for
> > all platforms including Windows?
> > 2) If so, would R-devel set the default multi-thread level to the number
> of
> > (real) cores on a machine?
> >
> > My sense is there're a lot of wasted resources on laptops and personal
> > desktops around the world that could be utilised by such a switch. I
> > believe most unix-like users don't know about OpenBLAS and are blissfully
> > ignorant of the available speed gains. It seems to be quite difficult
> for a
> > typical Windows user to get this done today.
> >
> > Thanks heaps,
> > Kenny
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Avraham Adler
On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell <[hidden email]> wrote:

> It seems like many of the multi-threaded BLASes have some sort of
> fundamental problem preventing use in the way Juan suggests:
>
>  - Dirk's vignette states that ATLAS "fixes the number of cores used at
> compile-time and cannot vary this setting at run-time", so any
> user-friendly implementation for R would have to compile ATLAS for 1-16
> threads to allow the user to switch at run-time. This might dramatically
> affect install times.
>
>  - MKL seems like it's been outright rejected in the past based on not
> being "free-enough".
>
>  - OpenBLAS causes crashes.
>
> Has anyone tried ExBLAS for use with R?
>
> On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder <
> [hidden email]> wrote:
>
>> I would be very cautious about OpenBLAS in particular...  from time to
>> time I get complains from users that compiled code calculations in my
>> WGCNA package crash or produce wrong answers with large data, and they
>> all come from OpenBLAS users. I am yet to reproduce any of their
>> crashes when using MKL and ATLAS BLAS implementations.
>>
>> Just my 2 cents...
>>
>> Peter

I've been building R on Windows 64 bit with OpenBLAS for years and my
builds pass check-devel. For a while in the past it failed one check
as the tolerance was 5e-5 and with my build of OpenBLAS the error was
5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall
correctly. I provide descriptions here [1], but I haven't gone so far
as to post compiled Rblas.dlls just yet. My personal build sets 4
threads when compiling OpenBLAS itself as I'm currently on a quad-core
SandyBridge. In tests I ran a few years ago, both single and multi
threaded BLAS compile and then can be compiled into R with no issues
(on my platforms, at least). Most matrix operations performed better
with multi-threaded except for R's eigenvalue decomposition, to the
nest of my recollection.

Avi

[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Juan Telleria
Julia Programming Language uses also OpenBlas, and it is actively
maintained with bugs being fixed as I have checked it out:

http://www.openblas.net/Changelog.txt

So I still see it ok to be included as an options(...) feature (by default
off, just for safety), over other Blas libraries.

R could not use Intel MKL for legal reasons (I think), because as long that
R ships with GPL libraries, shipping R by default with Non-GPL is illegal.

Cheers,
Juan

El 17/12/2017 2:50 a. m., "Avraham Adler" <[hidden email]>
escribió:

> On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell <[hidden email]> wrote:
> > It seems like many of the multi-threaded BLASes have some sort of
> > fundamental problem preventing use in the way Juan suggests:
> >
> >  - Dirk's vignette states that ATLAS "fixes the number of cores used at
> > compile-time and cannot vary this setting at run-time", so any
> > user-friendly implementation for R would have to compile ATLAS for 1-16
> > threads to allow the user to switch at run-time. This might dramatically
> > affect install times.
> >
> >  - MKL seems like it's been outright rejected in the past based on not
> > being "free-enough".
> >
> >  - OpenBLAS causes crashes.
> >
> > Has anyone tried ExBLAS for use with R?
> >
> > On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder <
> > [hidden email]> wrote:
> >
> >> I would be very cautious about OpenBLAS in particular...  from time to
> >> time I get complains from users that compiled code calculations in my
> >> WGCNA package crash or produce wrong answers with large data, and they
> >> all come from OpenBLAS users. I am yet to reproduce any of their
> >> crashes when using MKL and ATLAS BLAS implementations.
> >>
> >> Just my 2 cents...
> >>
> >> Peter
>
> I've been building R on Windows 64 bit with OpenBLAS for years and my
> builds pass check-devel. For a while in the past it failed one check
> as the tolerance was 5e-5 and with my build of OpenBLAS the error was
> 5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall
> correctly. I provide descriptions here [1], but I haven't gone so far
> as to post compiled Rblas.dlls just yet. My personal build sets 4
> threads when compiling OpenBLAS itself as I'm currently on a quad-core
> SandyBridge. In tests I ran a few years ago, both single and multi
> threaded BLAS compile and then can be compiled into R with no issues
> (on my platforms, at least). Most matrix operations performed better
> with multi-threaded except for R's eigenvalue decomposition, to the
> nest of my recollection.
>
> Avi
>
> [1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenBLAS in everyday R?

Kenny Bell-2
Julia using OpenBLAS is *very* reassuring.

I agree that having it included as an options(...) feature should be OK.

On Sun, Dec 17, 2017, 3:22 PM Juan Telleria <[hidden email]> wrote:

> Julia Programming Language uses also OpenBlas, and it is actively
> maintained with bugs being fixed as I have checked it out:
>
> http://www.openblas.net/Changelog.txt
>
> So I still see it ok to be included as an options(...) feature (by default
> off, just for safety), over other Blas libraries.
>
> R could not use Intel MKL for legal reasons (I think), because as long
> that R ships with GPL libraries, shipping R by default with Non-GPL is
> illegal.
>
> Cheers,
> Juan
>
> El 17/12/2017 2:50 a. m., "Avraham Adler" <[hidden email]>
> escribió:
>
>> On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell <[hidden email]> wrote:
>> > It seems like many of the multi-threaded BLASes have some sort of
>> > fundamental problem preventing use in the way Juan suggests:
>> >
>> >  - Dirk's vignette states that ATLAS "fixes the number of cores used at
>> > compile-time and cannot vary this setting at run-time", so any
>> > user-friendly implementation for R would have to compile ATLAS for 1-16
>> > threads to allow the user to switch at run-time. This might dramatically
>> > affect install times.
>> >
>> >  - MKL seems like it's been outright rejected in the past based on not
>> > being "free-enough".
>> >
>> >  - OpenBLAS causes crashes.
>> >
>> > Has anyone tried ExBLAS for use with R?
>> >
>> > On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder <
>> > [hidden email]> wrote:
>> >
>> >> I would be very cautious about OpenBLAS in particular...  from time to
>> >> time I get complains from users that compiled code calculations in my
>> >> WGCNA package crash or produce wrong answers with large data, and they
>> >> all come from OpenBLAS users. I am yet to reproduce any of their
>> >> crashes when using MKL and ATLAS BLAS implementations.
>> >>
>> >> Just my 2 cents...
>> >>
>> >> Peter
>>
>> I've been building R on Windows 64 bit with OpenBLAS for years and my
>> builds pass check-devel. For a while in the past it failed one check
>> as the tolerance was 5e-5 and with my build of OpenBLAS the error was
>> 5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall
>> correctly. I provide descriptions here [1], but I haven't gone so far
>> as to post compiled Rblas.dlls just yet. My personal build sets 4
>> threads when compiling OpenBLAS itself as I'm currently on a quad-core
>> SandyBridge. In tests I ran a few years ago, both single and multi
>> threaded BLAS compile and then can be compiled into R with no issues
>> (on my platforms, at least). Most matrix operations performed better
>> with multi-threaded except for R's eigenvalue decomposition, to the
>> nest of my recollection.
>>
>> Avi
>>
>> [1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel