From kmbell56 at gmail.com  Sun Dec 17 00:11:32 2017
From: kmbell56 at gmail.com (Kenny Bell)
Date: Sun, 17 Dec 2017 12:11:32 +1300
Subject: [Rd] OpenBLAS in everyday R?
In-Reply-To: <CAB7vNPxm2ikpoj8HFzpwkckWQ-dJAQQ3NqO4qiT4tR1DBNBHVQ@mail.gmail.com>
References: <CAPekMCmNdaQdqJzDLJfNQb=T2X9TjhnZ-Ad9Gd0n6d1ku+Kk=A@mail.gmail.com>
 <23093.35234.227393.513580@bud.eddelbuettel.com>
 <CAB7vNPxm2ikpoj8HFzpwkckWQ-dJAQQ3NqO4qiT4tR1DBNBHVQ@mail.gmail.com>
Message-ID: <CAPekMC=Ohp+kCPYcB5mxMJg4L5iJfJEtAvfp+rSsKwgdkg7i8A@mail.gmail.com>

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 <keith.ohara at nyu.edu> 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 <edd at debian.org> 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]]
>> |
>> | ______________________________________________
>> | R-devel at r-project.org mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>

	[[alternative HTML version deleted]]



[Rd] OpenBLAS in everyday R?
Kenny Bell