Number of threads stuck on two

[Michael Rutter]

I backported openblas to natty using my Launchpad PPA. When installed on my system, I cannot get more than two threads to be used. I am using R as a test bed, manually linking the original libblas file to the one installed from binary. I tried changing the number of threads with environmental variables, but nothing worked.

The PPA buildlog has the following:

libopenblasp-r0.1alpha2.2.a (Multi threaded; Max num-threads is 2)

I believe this is setting the max limit of the threads. Can this be fixed to use the max number of threads on a particular system right out of the box?

[Sylvestre Ledru (sylvestre)]

What happens if you do ?

# apt-get source openblas

and type

# fakeroot debian/rules custom

it should produce a package called:
# ../libopenblas-base_*.deb

[Michael Rutter (marutter)]

When I build the package on my local machine, I get the correct number of threads, so that works fine.

However, the binary package available in universe for Oneiric and my attempt to back port it to Natty on launchpad is limited to two threads, because that is the number of threads available on the build machine (that is my hypothesis, at least). Is there a way to build a binary package that will use the maximum number of threads on the machine that downloaded the binary package?

Or in order to get more than two threads, will a user have to build the package on their machine then install? This is not a bad option, and one that could be automated.

[Julian Taylor (jtaylor)]

during compilation the number of threads of the build machine is hardcoded into the code:
gcc ... -DMAX_CPU_NUMBER=4

apparently the ubuntu build machine had two cores

with these type of libraries it is always better to build them on the machine your are using them one so you get the optimal performance.
binary packages can only provided the lowest common denominator.

[Thomas U. (thomas-unterthiner)]

FWIW, this bug is still present in 2.6.1. While I understand that it might be a sensible idea to define an upper bound on the number of CPUs used by default, it seems a bit restrictive to be stuck at 2 threads.

Since OpenBLAS comes with kernels that are optimized to the user's machine anyhow, having to recompile it just so we can use a decent number of threads is a bit restrictive. As long as the default number of threads remains something small (1, 2, or determined at runtime as #cores present), why disable the environment variables?

[Julian Taylor (jtaylor)]

it should be fixed in the next revision:
http://anonscm.debian.org/viewvc/debian-science/?view=revision&revision=45618

[Launchpad Janitor (janitor)]

This bug was fixed in the package openblas - 0.2.6-1

---------------
openblas (0.2.6-1) unstable; urgency=low

  * Upload to unstable
  * Update Standards-Version to 3.9.4
  * Increase the maximum number of threads to 64 when building the generic
    package. At runtime, OpenBLAS will not use more threads than there are
    available cores. (LP: #817212)

 -- Sébastien Villemot <email address hidden> Sat, 02 Mar 2013 17:46:01 +0100