On Fri, 17 Jan 2020, Sven Schreiber wrote:
Am 16.01.2020 um 17:42 schrieb Allin Cottrell:
> 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.
openblas_set_num_threads(1) is indeed one of the recommended ways
(
https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded)
BTW, slightly OT, but since you upgraded OpenBLAS to 0.3.7, the page
above also says:
"when OpenBLAS was built single-threaded by USE_THREAD=0 ... it is vital
to also specify USE_LOCKING=1 (introduced with OpenBLAS 0.3.7)"
I think normally gretl doesn't use single-threaded openblas, but it
sounds relevant for the exceptional cases where it wants to do that.
That's not an issue for us: "built single-threaded" is a compile-time
thing. We (I) compile openblas only for our Windows packages, and in
that context we're never going to supply a single-threaded build --
although the library will _run_ single-threaded is there's only one
processor on the user's system.
On Linux, it's up to the distro to ensure that a single-threaded
version of openblas (if relevant) is done right. And on Mac we use the
built-in Accelerate Framework instead.
Allin