Most BLAS implementations are thread safe, but some versions of OpenBLAS, for example, are not. This routine is a diagnostic helper function, which you will never need if you don't set nthreads>1, and even then are unlikely to need.
blas.thread.test(n=1000,nt=4)
Number of iterations to run of parallel BLAS calling code.
Number of parallel threads to use
Simon N. Wood simon.wood@r-project.org
While single threaded OpenBLAS 0.2.20 was thread safe, versions 0.3.0-0.3.6 are not, and from version 0.3.7 thread safety of the single threaded OpenBLAS requires making it with the option USE_LOCKING=1. The reference BLAS is thread safe, as are MKL and ATLAS. This routine repeatedly calls the BLAS from multi-threaded code and is sufficient to detect the problem in single threaded OpenBLAS 0.3.x.
A multi-threaded BLAS is often no faster than a single-threaded BLAS, while judicious use of threading in the code calling the BLAS can still deliver a modest speed improvement. For this reason it is often better to use a single threaded BLAS and the codenthreads options to bam or gam. For bam(...,discrete=TRUE) using several threads can be a substantial benefit, especially with the reference BLAS.
The MKL BLAS is mutlithreaded by default. Under linux setting environment variable MKL_NUM_THREADS=1 before starting R gives single threaded operation.