OMP...            OPENBLAS...       best of 3 runs <unset/default>   <unset/default>   6.4 s 4                 4                 6.4 s 4                 1                 6.4 s 1                 4                 2.9 s 1                 1                 2.9 s So the OPENBLAS... settings are irrelevant, but using only a single OMP thread is twice as fast than gretl's default setting! (In the script you see that the matrix dimensions are 200x10 and 200x80.) I guess the underlying Cholesky routine should be checked as well as the possible root cause.

Hi Sven, my machine is: 4 Hyper-Threaded Core i7-8550U CPU @ 1.80GHz. My results: OMP...            OPENBLAS...       best of 3 runs <unset/default>   <unset/default>   7.54 4                 4                 7.24 4                 1                 8.36 1                 4                 12.66 1                 1                 12.51

Am 22.01.20 um 14:47 schrieb Marcin Błażejowski: > > Hi Sven, > > my machine is: 4 Hyper-Threaded Core i7-8550U CPU @ 1.80GHz. > > My results: > > OMP...            OPENBLAS...       best of 3 runs > <unset/default>   <unset/default>   7.54 > 4                 4                 7.24 > 4                 1                 8.36 > 1                 4                 12.66 > 1                 1                 12.51 Thanks Marcin, that's interesting! Actually I have the same CPU in a laptop, so I could cross-check how the Windows package influences the whole thing. (I'm assuming you were on Linux with that test?) So as I suspected, it's not so easy in general. BTW, if you're really on Linux, do you know what your openblas version is?

4 Hyper-Threaded Core i7-7700U CPUs @ 4.20GHz (haswell) OMP_NUM_THREADS   best of 3 runs default: 8           1.9 s 4                    1.5 s 1                    1.4 s 4 Hyper-Threaded Core i7-2600 CPUs @ 3.40GHz (sandybridge) OMP_NUM_THREADS   best of 3 runs default: 8           3.9 s 4                    3.0 s 1                    2.7 s It seems pretty clear that in the SMT/HT case we should limit the number of blas threads to the number of actual cores by default -- I'll work on that. But beyond that point I think we're seriously getting into the weeds. Restricting openblas to single-threaded operation may be advantageous for some combinations of architecture, openblas variant, lapack function called, OS and problem-size but it's very hard to generalize.

That is something which bothers me: I have OpenBLAS 0.3.7+ds-7 taken from Debian repos (libopenblas-base:amd64 + libopenblas-openmp-dev:amd64) and gretl links (after a long alternatives chain) against '/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3' (and in case of LAPACK against '/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so.3'). Looks good: OpenBLAS witn OpenMP. But 'eval $sysinfo' produces following results: bundle anonymous:   ncores = 4   mpi = 1   omp = 1   hostname = "marcin-note"   os = "linux"   omp_num_threads = 4   mpimax = 8   blas = "netlib"   nproc = 8   wordlen = 64

On 23.01.2020 18:23, Allin Cottrell wrote: > On Thu, 23 Jan 2020, Marcin Błażejowski wrote: > >> That is something which bothers me: I have OpenBLAS 0.3.7+ds-7 taken >> from Debian repos (libopenblas-base:amd64 + >> libopenblas-openmp-dev:amd64) and gretl links (after a long alternatives >> chain) against '/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3' >> (and in case of LAPACK against >> '/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so.3'). Looks good: >> OpenBLAS witn OpenMP. But 'eval $sysinfo' produces following results: >> >> bundle anonymous: >>   ncores = 4 >>   mpi = 1 >>   omp = 1 >>   hostname = "marcin-note" >>   os = "linux" >>   omp_num_threads = 4 >>   mpimax = 8 >>   blas = "netlib" >>   nproc = 8 >>   wordlen = 64 > > Marcin, if the OS is not delivering the desired linkage via its > "alternatives" mechanism you can force the issue by defining > LAPACK_LIBS at gretl configure time. For example, on Fedora I'm doing Allin, but: 1. ldd /usr/local/bin/gretlcli | grep blas produces: libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 2. ll /usr/lib/x86_64-linux-gnu/libblas.so.3 gives: /usr/lib/x86_64-linux-gnu/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86_64-linux-gnu 3. ll /etc/alternatives/libblas.so.3-x86_64-linux-gnu gives: /etc/alternatives/libblas.so.3-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3 So, it looks like linking against OpenBLAS, am I right?

gretl links (after a long alternatives chain) against '/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3' (and in case of LAPACK against '/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so.3'). Looks good: OpenBLAS witn OpenMP. But 'eval $sysinfo' produces following results: bundle anonymous:   blas = "netlib"

On 23.01.2020 22:31, Allin Cottrell wrote: > On Thu, 23 Jan 2020, Marcin Błażejowski wrote: > >> gretl links (after a long alternatives chain) against >> '/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3' (and in >> case of LAPACK against >> '/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so.3'). Looks >> good: OpenBLAS witn OpenMP. But 'eval $sysinfo' produces following >> results: >> >> bundle anonymous: >>   blas = "netlib" > Please try with current git and see what blas variant gretl detects. And now I have: bundle anonymous:   ncores = 4   mpi = 1   omp = 1   hostname = "marcin-note"   os = "linux"   omp_num_threads = 4   mpimax = 8   blas = "openblas"   nproc = 8   wordlen = 64

On Wed, 22 Jan 2020, Sven S wrote: > Am 22.01.20 um 14:47 schrieb Marcin Błażejowski: >> my machine is: 4 Hyper-Threaded Core i7-8550U CPU @ 1.80GHz. >> >> My results: >> >> OMP...            OPENBLAS...       best of 3 runs >> <unset/default>   <unset/default>   7.54 >> 4                 4                 7.24 >> 4                 1                 8.36 >> 1                 4                 12.66 >> 1                 1                 12.51 > > Thanks Marcin, that's interesting! Actually I have the same CPU in a > laptop, so I could cross-check how the Windows package influences the > whole thing.

But beyond that point I think we're seriously getting into the weeds. Restricting openblas to single-threaded operation may be advantageous for some combinations of architecture, openblas variant, lapack function called, OS and problem-size but it's very hard to generalize.

I was finally able to get a speed advantage for 4 threads when I increased the problem size in the script to T=1000, N=40. So of course you're right that single-thread is not the universal solution. But it does seem that openblas tries multithreading much too aggressively.

Am 24.01.2020 um 20:58 schrieb Allin Cottrell: > There's a compile-time option for openblas that is apparently more > functional in 0.3.7 than it used to be. Quoting Makefile.rule: > > "If any gemm argument m, n or k is less or equal to > [GEMM_MULTITHREAD_THRESHOLD], gemm will be execute with single thread. > It might be worth trying the Julia value of 50. But this is applicable > only to our builds for Windows, or for people building the openblas > library themselves (e.g. on Linux). I haven't experimented yet but I > plan to. I had read about that, yes, but doesn't GEMM just apply to multiplication? Would this affect solvers as well?

On 17.01.2020 12:13, Sven Schreiber wrote: > I varied the environment variables OMP_NUM_THREADS and > OPENBLAS_NUM_THREADS: > > OMP...            OPENBLAS...       best of 3 runs > <unset/default>   <unset/default>   6.4 s > 4                 4                 6.4 s > 4                 1                 6.4 s > 1                 4                 2.9 s > 1                 1                 2.9 s > > Hi Sven again, my machine is still: 4 Hyper-Threaded Core i7-8550U CPU @ 1.80GHz, but this time we use new Allin's compiler/linker settings for Debian-like system to force linking against OpenBLAS (0.3.7 + OpenMP). My results: OMP...            OPENBLAS...       best of 3 runs <unset/default>   <unset/default>   2.067 4                 4                2.83 4                 1                2.83 1                 4                2.81 1                 1                2.80 ------------------------------------------ 8                 8                2.86 8                 4                2.81 4                 8                2.86 8                 1                2.81 1                 8                2.87 ------------------------------------------

I'm attaching shell script to run test for all possibilities. Cheers, Marcin _______________________________________________ Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/

On 28.01.2020 09:18, Sven Schreiber wrote: > But openblas alone doesn't explain the equality of the 4-thread and > the single-thread outcome, at least comparing to the Windows results. > Or did you compile openblas yourself? (Perhaps with a different dgemm > threshold?) > No, I did not. This is a standard debian package (libopenblas0-openmp:amd64), but I'm going to compile it so:

what dgemm threshold does?

>> On 28.01.2020 09:18, Sven Schreiber wrote: >>> But openblas alone doesn't explain the equality of the 4-thread and >>> the single-thread outcome, at least comparing to the Windows results. >>> Or did you compile openblas yourself? (Perhaps with a different dgemm >>> threshold?) >>> This is 'libopenblas-base:amd64 0.3.7+ds-7' which is transitional to (in my case) 'libopenblas0:amd64 0.3.7+ds-7' which is meta package and true one is 'libopenblas0-openmp:amd64 0.3.7+ds-7'.

On 24.01.2020 14:28, Allin Cottrell wrote: > On Fri, 24 Jan 2020, Marcin Błażejowski wrote: > >> On 23.01.2020 22:31, Allin Cottrell wrote:

>>> Please try with current git and see what blas variant gretl detects. >> And now I have: >> >> bundle anonymous: >>   ncores = 4 >>   mpi = 1 >>   omp = 1 >>   hostname = "marcin-note" >>   os = "linux" >>   omp_num_threads = 4 >>   mpimax = 8 >>   blas = "openblas" >>   nproc = 8 >>   wordlen = 64 > Hmm, you're not getting entries for "blas_parallel" or "blascore"? No, that's all I get.

On 31.01.2020 10:54, Sven Schreiber wrote: > On another Linux machine I now also have the libopenblas0-openmp package > from Debian bullseye (=testing, I believe) which should be 0.3.7. And > today's gretl git. I'm not getting blas_parallel and blascore in > $sysinfo, either, although I saw that in later messages than this one > Marcin had it. Sven, two fings: type 'make clean' and run configure again. You may also (before configuring) type "export LAPACK_LIBS='-lopenblas -lgfortran'"