Make RhpcBLASctl Suggests?

{RhpcBLASctl} is AGPL-licensed, which makes it invalid for import at many orgs, Google included:

https://opensource.google/documentation/reference/using/agpl-policy

The RhpcBLASctl author confirmed this choice is intentional, but it makes using downstream packages like {rsparse} difficult as well.

To use it, I've patched out the requirement, which AFAICT is about supporting parallelism for performance.

Because it will just make the code slower, I think making {RhpcBLASctl} optional makes sense to more readily support users who can't install it.

Would you accept a PR?

I am not sure this would be a good idea. It is used to disable multi-threading in BLAS (not sure if syr, syrk, gemm, or gemmt) and LAPACK (potrf, potrs) calls when those are already parallelized through openmp.

If this were to be disabled (as it would be by default without RhpcBLASctl), under some BLASes, there could be a slowdown that users might not know about or might not know how to address.

I guess the most popular choice for BLAS/LAPACK on linux is openblas-pthreads, which not would adjust its threads automatically when running under an OMP section.

I guess it shouldn't be a problem with syrk and potrf/potrs calls in the latest version of openblas when the problem sizes are small (OpenMathLib/OpenBLAS#3237 OpenMathLib/OpenBLAS#3284 OpenMathLib/OpenBLAS#3244), and it shouldn't be a problem with the '-openmp' version either, nor with MKL; but I don't know for sure what exact functions armadillo would be calling behind the scenes, and don't know about other BLASes like apple's.

Would it be possible to run some benchmarks with/without the RhpcBLASctl calls of the affected routines with different software like apple's blas and openblas-pthreads?

I'm not against adding it to "Suggests". But I think there should be some mechanism to warn users or internal capability to limit BLAS threading. With both BLAS multithreading and outer loop OMP multithreading the thread contention is severe.

It could be an .onAttach() warning, where if {RhpcBLASctl} is not found, the user sees a strong exhortation on startup?

#83 has some GHA benchmarks to investigate this quantitatively.

Summary of the benchmark:

# ubuntu-latest:
    omp_threads blas_control      time
  1           1         TRUE 14.023614
  2           2         TRUE  7.153234
  3           1        FALSE 11.920999
  4           2        FALSE  9.739764

# macos-latest:
    omp_threads blas_control     time
  1           1         TRUE 15.68406
  2           2         TRUE 16.58050
  3           1        FALSE 22.79602
  4           2        FALSE 28.21602

Ubuntu-latest (Linux, OpenBLAS, 2 cores)

Optimal (OMP=2, Control=TRUE): 7.15 seconds (almost perfect 2x speedup).
Uncontrolled (OMP=2, Control=FALSE): 9.74 seconds (36% slower).
The absolute difference is now 2.59 seconds.

macos-latest (macOS, Accelerate)

Optimal (OMP=2, Control=TRUE): 16.58 seconds (no OMP speedup, likely due to serial LAPACK or GHA macOS compiler configuration).
Uncontrolled (OMP=2, Control=FALSE): 28.22 seconds (70% slower).
Even without OpenMP speedup, the lack of BLAS control causes a massive 11.64 seconds penalty due to Accelerate's multi-threading overhead/contention.

Navigation Menu

Repository navigation

Make RhpcBLASctl Suggests? #82

Ubuntu-latest (Linux, OpenBLAS, 2 cores)

macos-latest (macOS, Accelerate)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Make RhpcBLASctl Suggests? #82

Description

Activity

david-cortes commented on Jun 16, 2026

dselivanov commented on Jun 29, 2026

MichaelChirico commented on Jun 30, 2026

MichaelChirico commented on Jun 30, 2026

MichaelChirico commented on Jun 30, 2026

Ubuntu-latest (Linux, OpenBLAS, 2 cores)

macos-latest (macOS, Accelerate)

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions