Has anyone succeeded in getting a parallel BLAS, such as Goto's BLAS, installed on a machine running Ubuntu 11.10? I currently have the libatlas3gf-base package installed on a machine with an AMD Athlon X4 processor. I tried to install the libopenblas-base and libopenblas-dev packages but there seemed to be a glich related to having both libopenblas and libatlas3gf installed so that when I tried to recompile R it failed to start because one of the ATL symbols from Atlas was undefined. Is it worthwhile making a custom version of Atlas? Every time I try to compile a local version of Atlas it fails because of CPU Throttling being enabled. I suppose I could reboot after tweaking the BIOS then compile then shutdown then tweak the BIOS but that seems like a complicated route to getting optimized BLAS.
On Thu, Nov 10, 2011 at 1:21 PM, Douglas Bates <bates at stat.wisc.edu> wrote:> Has anyone succeeded in getting a parallel BLAS, such as Goto's BLAS, > installed on a machine running Ubuntu 11.10? > > I currently have the libatlas3gf-base package installed on a machine > with an AMD Athlon X4 processor. ?I tried to install the > libopenblas-base and libopenblas-dev packages but there seemed to be a > glich related to having both libopenblas and libatlas3gf installed so > that when I tried to recompile R it failed to start because one of the > ATL symbols from Atlas was undefined.I found out what the problem was through that devious approach of reading the documentation :-) After installing libopenblas-base you need to run sudo update-alternatives --config liblapack.so.3gf and choose the library in /usr/lib/lapack.> Is it worthwhile making a custom version of Atlas? ?Every time I try > to compile a local version of Atlas it fails because of CPU Throttling > being enabled. ?I suppose I could reboot after tweaking the BIOS then > compile then shutdown then tweak the BIOS but that seems like a > complicated route to getting optimized BLAS. >
Added back the cc: to the R-SIG-Debian list On Fri, Nov 11, 2011 at 11:13 AM, Paul Johnson <pauljohn32 at gmail.com> wrote:> Speaking of GotoBLAS, have you run into the problem of thread > management conflicts with RMPI? ?In order to use GotoBLAS, the > submission script on our cluster has to explicitly restrict GotoBLAS's > effort to claim threads or else the jobs slow to a crawl as threads > multiply out of control. ?It got to be enough of a hassle that I > stepped back from the whole Goto experience. > > Is it not a trouble now?OpenBLAS will try to grab as many threads as there are cores available if you do not specify otherwise. This is rather impolite behavior but comes from people wanting to squeeze out every possible cycle that they can. One nice thing about the libopenblas-base package when recompiled locally is that there are several different environment variables that can be used to control the number of threads that it uses. You can always set the environment variable OMP_NUM_THREADS=2 but that will apply to all code using openmp. If you set OPENBLAS_NUM_THREADS=2 you can separately control other code using openmp. The parallel package in R-2.14.0 and later uses similar controls.