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]]
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]]
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]]