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.oh...@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 <e...@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@r-project.org mailing list >> | https://stat.ethz.ch/mailman/listinfo/r-devel >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
