[Gretl-devel] Re: MPI and OpenMP (and openblas?)

On Thu, 16 Jan 2020, Sven Schreiber wrote: I can't replicate the problem Sven describes, either on Linux or on Windows 10. In each case it seems that the gretl mpi-block option --omp-threads successfully controls the number of OMP threads, taking precedence over a setting of OMP_NUM_THREADS in the environment. When the user specifies omp-threads, libgretl calls the libgomp function omp_set_num_threads(), and as I understand it that should limit the number of threads used in calls to OpenMP from libgretl. In light of Sven's account I wondered whether this libgomp-level setting was not "getting through" to the openblas library, but in my testing it appears to be working fine. Nonetheless, I've added a call to openblas_set_num_threads() just in case that makes a difference on some systems. (Well, it presumably _will_ make a difference on systems where openblas uses raw pthreads rather than OMP, but that's not the case in our packages for Windows.) Here's the test I was running. It relies on the fact that our old svd code ran significantly faster without multi-threading, so GRETL_OLD_SVD=1 should be in the environment. I collected timings for various values of OMP_NUM_THREADS and --omp-threads and found that --omp-threads was the controlling factor. <hansl> set verbose off mpi set seed 987654 matrix U matrix V k = 40 N = floor(5000000/k^2) matrix X = mnormal(110,k) set stopwatch loop N -q matrix s = svd(X, &U, &V) endloop printf "k = %d, elapsed: %#gs\n", k, $stopwatch end mpi --np=2 --omp-threads=1 # or increase </hansl> Allin