On 11 November 2011 at 11:45, Douglas Bates wrote: | Added back the cc: to the R-SIG-Debian list | | On Fri, Nov 11, 2011 at 11:13 AM, Paul Johnson <[email protected]> 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.
... because it also uses the OpenMP constructs provided by gcc: That said, I just grep'ed madly in the sources of parallel (as per R 2.14.0) and didn't see it, nor did I see it in the vignette. I could swear I read it in an earlier pre-release version of the parallel vignette. Hmm. Dirk -- "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read." -- Groucho Marx _______________________________________________ R-SIG-Debian mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-debian
