Re: [Gretl-devel] MPI doc
Am 17.02.2015 um 14:23 schrieb Allin Cottrell:
On Tue, 17 Feb 2015, Sven Schreiber wrote:
> In the last line the gretl interpreter would just have to know that
> the "b" to be broadcast lives in rank 0. I don't see why it would have
> to know about non-existing b's in other ranks.
You have n copies of the gretl interpreter running.
This is something I wasn't yet fully aware of I guess...
that are not at rank 0 would have to parse the hansl code
"hidden
behind" the condition $mpirank == 0 and record the names and types of
all variables declared therein, so that if any of these names later
appeared in broadcast or scatter calls they would be recognized.
Ok, so if I understand correctly, without pre-declaration it's not
possible for the rank-0-interpreter to tell the other interpreters
"watch out there's a 'b' coming your way" because there's
currently no
mechanism that allows the rank-0-interpreter to enclose the necessary
information "hey guys, 'b' is a matrix (with dimensions
such-and-such)"?
Or is it rather that the memory allocation really has to happen at an
early stage internally with Mpi?
> This is all just about idiomatic syntax I think: C and (I guess)
Mpi
> do pre-declaration all the time. Hansl doesn't. I'm not saying one is
> always better than the other, but I would like Hansl to stay Hansl as
> much as possible.
I take your point and thank you for getting a discussion going on this.
My feeling is that there's a definite programming paradigm associated
with MPI -- which seems strange and confusing at first but has a clear
logic that becomes apparent after you've worked with it for a little --
and that gretl users who want to use MPI are best advised to master this
logic. So I'm skeptical about trying to "sweeten the pill".
Mostly thanks to the excellent documentation that Jack and you are
putting together all this stuff can be mastered quite easily, yes. But I
don't actually feel like I'm departing a lot from that paradigm by
suggesting to delay the creation of objects a little..
thanks,
sven