[Gretl-devel] Re: MPI and OpenMP (and openblas?)
On Thu, 16 Jan 2020, Sven Schreiber wrote:
Am 16.01.2020 um 22:18 schrieb Allin Cottrell:
> On Thu, 16 Jan 2020, Sven Schreiber wrote:
>
>> Am 16.01.2020 um 19:50 schrieb Sven Schreiber:
>> The slowdowns of the previous message with Allin's script (e.g.
>> --omp-threads=2 and OMP_NUM_THREADS=2) were much more drastic, however.
>
> I can't replicate those slowdowns on Linux (for each --omp-threads
> case, times are invariant with respect to the OMP_NUM_THREADS setting)
> but I'll try on Windows tomorrow.
I'm seeing this on another machine as well, timings going from roughly
2.5s to 8.5s when OMP_NUM_THREADS=1 is changed to OMP_NUM_THREADS=2 (and
--omp-threads=2). This was still the Jan-11th snapshot.
Then I have upgraded to the latest snapshot of "just now". There I don't
see a noticeable difference anymore - but that's because both variants
are now slow!
Like this:
GRETL_OLD_SVD is 1
OMP_NUM_THREADS is 1
--omp-threads option is 2
Entering MPI real-time read loop
gretlmpi 2020a-git
Aktuelle Sitzung: 2020-01-16 23:08
k = 40, elapsed: 8.36354s
k = 40, elapsed: 8.50609s
On the maintained hypothesis that single-threaded is fastest for
DGESVD, I think the interpretation has to be the following (though I
can't really say I understand it yet):
* Under the old scheme, OMP_NUM_THREADS=1 was overriding the
omp-threads setting (because OMP_NUM_THREADS got higher priority in
general, or because the minimum value ruled, or because omp-threads
was somehow just ignored at openblas level).
* Under the new scheme omp-threads rules, so you'll get slow results
with that set to 2 regardless of the OMP_NUM_THREADS setting --
which is, I think, as it should be.
If that's right, the only real cause for concern would be if you
now (but how?!) get slow performance with --omp-threads=1.
Allin