FS#58563 - [r] Switch to openblas to improve performance?

Attached to Project: Arch Linux
Opened by Alex (zreeon) - Saturday, 12 May 2018, 15:56 GMT
Last edited by Antonio Rojas (arojas) - Monday, 02 July 2018, 09:49 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Ronald van Haren (pressh)
Antonio Rojas (arojas)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

openblas in [community] gives consistently better performance for me than the default blas in [extra].

Running this script[1], for example, with the default blas takes 36.963 seconds. With openblas it takes 7.109 seconds.

Additional info:
* r version 3.5.0-1

[1]: http://r.research.att.com/benchmarks/R-benchmark-25.R
This task depends upon

Closed by  Antonio Rojas (arojas)
Monday, 02 July 2018, 09:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  added optdepend in 3.5.1
Comment by Doug Newgard (Scimmia) - Saturday, 12 May 2018, 16:04 GMT
openblas provides blas. If you want it, install it. I don't see what the problem is.
Comment by Alex (zreeon) - Saturday, 12 May 2018, 16:09 GMT
The problem as I see it is that r's performance out-of-the-box can be substantially improved for many use cases by using openblas rather than blas. Instead of assuming users research which blas implementation they want to use, shouldn't Arch just provide the fastest? As far as I understand, there's no downside to switching to openblas.
Comment by Allan McRae (Allan) - Sunday, 13 May 2018, 01:21 GMT
From all the benchmarks I can find, there is no reason not to swap blas with openblas in R. Other packages (e.g. numpy) also show a large benefit.
Comment by Antonio Rojas (arojas) - Sunday, 13 May 2018, 07:42 GMT
-1 from me to enforcing any particular blas implementation. There are some other popular optimized implementations out there, what if someone wants to use Atlas because it works better for them? Our job is to make sure that everything works with every compatible implementation and to inform users of the options, not to choose for them.

To be constructive, other alternatives that I would find more appropriate:
- Adding openblas to optdepends
- Switching all blas linked packages to sodeps so users get to choose explicitly at install time

In any case, this is something that should be discussed for all packages using blas, not on a case by case basis.
Comment by Eli Schwartz (eschwartz) - Sunday, 13 May 2018, 13:10 GMT
Is there a specific benefit to blas, that we need to provide it in addition to openblas? Maybe we could just keep providing one blas implementation, but switch to that being openblas instead of blas, now that we ship the former?
Comment by Alex (zreeon) - Wednesday, 27 June 2018, 22:05 GMT

Loading...