On Fri, 12 Apr 2019, Sven Schreiber wrote:
Am 11.04.2019 um 22:20 schrieb Allin Cottrell:
> On Thu, 11 Apr 2019, Artur Tarassow wrote:
>
>> Am 11.04.19 um 18:12 schrieb Sven Schreiber:
>>> Am 11.04.2019 um 17:55 schrieb Artur Tarassow:
>>>> Just out of curiosity: Gretl wouldn't compute stuff in parallel
>>>> out-of-box, right?
>>>
>>> Hehe, well if "somebody" implemented the cross-array operation
natively
>>> and used OpenMP or stuff like that then perhaps it would... otherwise:
>>> not, I guess.
>>
>> Of course, I rather meant (without saying it explicitly) whether there
>> is some way to exploit C in a simple way to do this. But I guess this
>> is rather a non-trivial issue...
>
> Yes, non-trivial. The thing is, with feval() "anything could happen"
> (that is, any part of the libgretl code could be visited as a result of
> the function call). Getting this right with OpenMP would require that
> libgretl as a whole is thread-safe.
Hm, not sure I understand this point in the given context. What I
thought Artur meant is that for a given array of matrices the same
operation should be applied to every array member.
That was my understanding too.
That sounds to me like a natural parallelization task without race
conditions and so on.
The point is that "the same operation", executed by each of the
threads on its matrix, could involve calls to any gretl function,
built-in or user-defined, that accepts a matrix argument. And we know
that not every such function is currently thread-safe. Libgretl uses
static variables in quite a few places; thread-safe functions cannot
employ such variables without converting them to so-called
thread-local storage (TLS).
This is not an issue with MPI, since when multiple instances of gretl
are running -- as opposed to multiple threads under a single instance
-- each one automatically gets its own memory segment and its own
copies of any static variables.
Allin