7:29 a.m.
Good morning,
is the help file for parallel MPI from June or July 2014 still current?
The bootstrap example (which is very instructive) in there seems to me
as if it could be simplified for straightforward "everyday" use. I want
to make concrete suggestions, so I want to make sure I'm not referencing
outdated stuff.
Thanks,
sven
8:22 a.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Good morning,
is the help file for parallel MPI from June or July 2014 still current?
The bootstrap example (which is very instructive) in there seems to me
as if it could be simplified for straightforward "everyday" use. I want
to make concrete suggestions, so I want to make sure I'm not referencing
outdated stuff.
Yes, it should be ok. Is anything broken?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:16 p.m.
Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Good morning,
>
> is the help file for parallel MPI from June or July 2014 still current?
> The bootstrap example (which is very instructive) in there seems to me
> as if it could be simplified for straightforward "everyday" use. I want
> to make concrete suggestions, so I want to make sure I'm not referencing
> outdated stuff.
Yes, it should be ok. Is anything broken?
No (or at least I haven't found out yet), but I think the example is too
sophisticated. I mean, the example is excellent and shouldn't go away,
but IMO there should be something of the "Hello world" type, much
shorter. I will try to produce a minimal example.
In the meantime, two questions:
1) In the code snippet at the bottom of p.5, is "if $mpirank > 0"
correct, or should it rather be "if $mpirank == 0" ?
2) AFAICS the mpi block is encapsulated like a function body, that is no
variables/objects from outside the mpi block can be directly used
inside. The analogy to the "foreign" block is clearly explained, but
intuitively I think there is a difference: the mpi feature is supposed
to be part of gretl, so I do not quite like it that suddenly the scoping
rules within a hansl script change.
(IMHO the "foreign" block is a valid exception because the word
"foreign" itself is sufficiently self-explanatory that the user
understands that we are leaving the gretl world there.)
thanks,
sven
1:45 p.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
>> Good morning,
>>
>> is the help file for parallel MPI from June or July 2014 still current?
>> The bootstrap example (which is very instructive) in there seems to me
>> as if it could be simplified for straightforward "everyday" use. I
want
>> to make concrete suggestions, so I want to make sure I'm not referencing
>> outdated stuff.
>
> Yes, it should be ok. Is anything broken?
No (or at least I haven't found out yet), but I think the example is too
sophisticated. I mean, the example is excellent and shouldn't go away, but
IMO there should be something of the "Hello world" type, much shorter. I will
try to produce a minimal example.
OK, thanks.
In the meantime, two questions:
1) In the code snippet at the bottom of p.5, is "if $mpirank > 0" correct,
or
should it rather be "if $mpirank == 0" ?
Looks like it should be "if $mpirank == 0". I'll fix that.
2) AFAICS the mpi block is encapsulated like a function body, that is
no
variables/objects from outside the mpi block can be directly used inside. The
analogy to the "foreign" block is clearly explained, but intuitively I think
there is a difference: the mpi feature is supposed to be part of gretl, so I
do not quite like it that suddenly the scoping rules within a hansl script
change.
I see what you mean, but it would be difficult to do otherwise. As
with "foreign", an MPI block means that a distinct program is being
launched, with its own address space. No variables carry over
automatically, anything that's wanted has to be communicated via file.
But I suppose we could consider trying to make this "transparent" to
the user (i.e. transmit everything in the background, probably via an
XML serialization).
Allin
2:03 p.m.
Am 16.02.2015 um 14:45 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> 2) AFAICS the mpi block is encapsulated like a function body,
that is
> no variables/objects from outside the mpi block can be directly used
> inside. The analogy to the "foreign" block is clearly explained, but
> intuitively I think there is a difference: the mpi feature is supposed
> to be part of gretl, so I do not quite like it that suddenly the
> scoping rules within a hansl script change.
I see what you mean, but it would be difficult to do otherwise. As with
"foreign", an MPI block means that a distinct program is being launched,
with its own address space. No variables carry over automatically,
anything that's wanted has to be communicated via file. But I suppose we
could consider trying to make this "transparent" to the user (i.e.
transmit everything in the background, probably via an XML serialization).
I guess that would be good, or change the "mpi" block to "foreign
language=mpihansl". (I'm not 100% serious here, but it would be a clear
signal.) My first priority here is not asking for a new feature but
having a reasonably clean syntax.
Another thought I was having is whether these scripts can be made
portable, in the sense that they would also run on a machine without MPI
(in a single process then, of course). But I still have to get familiar
with the gretl-mpi setup.
thanks,
sven
2:41 p.m.
Am 16.02.2015 um 14:45 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
>>
>> Yes, it should be ok. Is anything broken?
>
> No (or at least I haven't found out yet), but I think the example is
> too sophisticated. I mean, the example is excellent and shouldn't go
> away, but IMO there should be something of the "Hello world" type,
> much shorter. I will try to produce a minimal example.
OK, thanks.
Hm, I'm not getting very far, see the following error output for an
empty mpi block, the error message says "invalid option '--np'":
<scriptoutput>
gretl-Version 1.10.0cvs
Aktuelle Sitzung: 2015-02-16 15:34
? bundle sb = $sysinfo
? scalar gmpi = sb.mpi
Erzeugte Skalar gmpi = 1
? print gmpi
gmpi = 1.0000000
? mpi
? end mpi --np=2
ungültige Option '--np'
Fehler bei Skriptausführung: Stopp
end mpi --np=2
</scriptoutput>
This is on 64bit Win7 with latest gretl snapshot, and I installed
Microsoft's MPI and entered the path in the gretl MPI settings. The
output from $sysinfo.mpi seems to indicate that gretl found the MPI
stuff ok.
And BTW, if I rerun the script after this error, then I get another error:
"? mpi
foreign: a block is already started"
which reminds me of earlier times when gretl wasn't always recovering
cleanly from execution interrupts.
thanks,
sven
3:54 p.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Am 16.02.2015 um 14:45 schrieb Allin Cottrell:
> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
>> Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
>>>
>>> Yes, it should be ok. Is anything broken?
>>
>> No (or at least I haven't found out yet), but I think the example is
>> too sophisticated. I mean, the example is excellent and shouldn't go
>> away, but IMO there should be something of the "Hello world" type,
>> much shorter. I will try to produce a minimal example.
>
> OK, thanks.
>
Hm, I'm not getting very far, see the following error output for an
empty mpi block, the error message says "invalid option '--np'":
<scriptoutput>
gretl-Version 1.10.0cvs
Aktuelle Sitzung: 2015-02-16 15:34
? bundle sb = $sysinfo
? scalar gmpi = sb.mpi
Erzeugte Skalar gmpi = 1
? print gmpi
gmpi = 1.0000000
? mpi
? end mpi --np=2
ungültige Option '--np'
Glad you spotted that. It's fallout from the "new tokenizer" -- but
not really a bug in the tokenizer, rather that option placement was
supported by a nasty piece of ad-hocery before. I need to think about
the best way of enabling it again. In the meantime you can add the
--np option to the first line of the mpi block instead of the last.
Allin
4:09 p.m.
Am 16.02.2015 um 16:54 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> ? mpi
> ? end mpi --np=2
> ungültige Option '--np'
Glad you spotted that. It's fallout from the "new tokenizer" -- but not
really a bug in the tokenizer, rather that option placement was
supported by a nasty piece of ad-hocery before. I need to think about
the best way of enabling it again. In the meantime you can add the --np
option to the first line of the mpi block instead of the last.
Yes that works -- actually I think the top is a much better location for
the options than the bottom, so from my point of view no need to change
anything (except the docs). Or what was the rationale behind putting the
options at the end?
thanks,
sven
4:27 p.m.
Am 16.02.2015 um 16:54 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Am 16.02.2015 um 14:45 schrieb Allin Cottrell:
>> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>>
>>> Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
>
>>>>
>>>> Yes, it should be ok. Is anything broken?
>>>
>>> No (or at least I haven't found out yet), but I think the example is
>>> too sophisticated. I mean, the example is excellent and shouldn't go
>>> away, but IMO there should be something of the "Hello world" type,
>>> much shorter. I will try to produce a minimal example.
>>
>> OK, thanks.
>>
Advancing line-by-line here... Next error below the sample script:
<hansl>
mpi --np=2
if $mpirank == 0 # parent process
matrix b = ones(1000,1)
matrix a = zeros(1000,1)
endif
# -- up to here no errors --
# divide up the input data
mpiscatter(&b, byrows)
/*
mpiscatter(&a, byrows)
# this is the parallelized operation
matrix c = b + a
# collect the results
mpireduce(&c, vstack)
*/
end mpi
</hansl>
And this is the error output:
<output>
gretlmpi 1.10.0cvs
Aktuelle Sitzung: 2015-02-16 17:23
job aborted:
[ranks] message
[0] terminated
[1] application aborted
aborting MPI_COMM_WORLD (comm=0x44000000), error 1, comm rank 1
---- error analysis -----
[1] on <machine-ID removed>
C:\Program Files\gretl\gretlmpi aborted the job. abort code 1
---- error analysis -----
</output>
The hardware is a Core i5 laptop, so I think this should have (at
least?) two CPU cores.
any ideas?
thanks,
sven
4:58 p.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Advancing line-by-line here... Next error below the sample script:
<hansl>
mpi --np=2
if $mpirank == 0 # parent process
matrix b = ones(1000,1)
matrix a = zeros(1000,1)
endif
# -- up to here no errors --
# divide up the input data
mpiscatter(&b, byrows)
The trouble here is that the matrices a and b exist only in the rank 0
process; they need to exist everywhere.
<hansl>
mpi --np=2
matrix a
matrix b
if $mpirank == 0
b = ones(1000,1)
a = zeros(1000,1)
endif
mpiscatter(&b, byrows)
</hansl>
Allin
5:21 p.m.
Am 16.02.2015 um 17:58 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Advancing line-by-line here... Next error below the sample script:
>
> <hansl>
> mpi --np=2
> if $mpirank == 0 # parent process
> matrix b = ones(1000,1)
> matrix a = zeros(1000,1)
> endif
> # -- up to here no errors --
>
> # divide up the input data
> mpiscatter(&b, byrows)
The trouble here is that the matrices a and b exist only in the rank 0
process; they need to exist everywhere.
<hansl>
mpi --np=2
matrix a
matrix b
if $mpirank == 0
b = ones(1000,1)
a = zeros(1000,1)
endif
mpiscatter(&b, byrows)
</hansl>
Hm, ok I understand. My spontaneous reaction would be: "but isn't this
what mpiscatter (or mpibroadcast) is supposed to achieve as part of
their job?".
What's the value added of requiring the pre-existence of the recipient
objects? It can't be the danger of name clashes, because AFAICS they are
not avoided this way, either. Or would it raise an error if the b matrix
in some other processes already contained other data and were overwritten?
thanks,
sven
5:42 p.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Am 16.02.2015 um 17:58 schrieb Allin Cottrell:
> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
>> Advancing line-by-line here... Next error below the sample script:
>>
>> <hansl>
>> mpi --np=2
>> if $mpirank == 0 # parent process
>> matrix b = ones(1000,1)
>> matrix a = zeros(1000,1)
>> endif
>> # -- up to here no errors --
>>
>> # divide up the input data
>> mpiscatter(&b, byrows)
>
> The trouble here is that the matrices a and b exist only in the rank 0
> process; they need to exist everywhere.
>
> <hansl>
> mpi --np=2
> matrix a
> matrix b
> if $mpirank == 0
> b = ones(1000,1)
> a = zeros(1000,1)
> endif
> mpiscatter(&b, byrows)
> </hansl>
>
Hm, ok I understand. My spontaneous reaction would be: "but isn't this what
mpiscatter (or mpibroadcast) is supposed to achieve as part of their job?".
What's the value added of requiring the pre-existence of the recipient
objects?
It's not a question of value added, it's just how MPI works! Remember
that each "rank" corresponds to a distinct instance of gretlmpi.
Consider your original code, without the prior declaration of the
matrices, from the point of view of the rank 1 process: the first line
rank 1 sees is:
mpiscatter(&b, byrows)
So it's like, "mpiscatter what?? I don't know anything about this b".
Allin
5:51 p.m.
Am 16.02.2015 um 18:42 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Am 16.02.2015 um 17:58 schrieb Allin Cottrell:
>> The trouble here is that the matrices a and b exist only in the rank 0
>> process; they need to exist everywhere.
>>
>> <hansl>
>> mpi --np=2
>> matrix a
>> matrix b
>> if $mpirank == 0
>> b = ones(1000,1)
>> a = zeros(1000,1)
>> endif
>> mpiscatter(&b, byrows)
>> </hansl>
>>
>
> Hm, ok I understand. My spontaneous reaction would be: "but isn't this
> what mpiscatter (or mpibroadcast) is supposed to achieve as part of
> their job?".
> What's the value added of requiring the pre-existence of the recipient
> objects?
It's not a question of value added, it's just how MPI works! Remember
that each "rank" corresponds to a distinct instance of gretlmpi.
Consider your original code, without the prior declaration of the
matrices, from the point of view of the rank 1 process: the first line
rank 1 sees is:
mpiscatter(&b, byrows)
So it's like, "mpiscatter what?? I don't know anything about this b".
Yeah, I actually understood that :-)
But since we're on the gretl list my comment was aimed at the hansl
wrapper implementation: Why can't hansl see the &b in mpiscatter(&b,
byrows) and shout out: "Hey I've seen this b before, it was created in
line xyz, and now everybody's getting it, too." I mean this look-up of
existing objects is what the interpreter does all the time, no?
Then you could tell me "but what if there are several b's out there in
different processes, which one should I use for scattering?" And I would
say "isn't this the same problem in the current status quo?".
Look, all this is probably much easier to criticize than to implement, I
know that. But from a user's point of view it's a hansl dialect in that
mpi block, and it should feel as hanslish as possible IMO.
thanks,
sven
6:21 p.m.
On Mon, 16 Feb 2015, Sven Schreiber wrote:
Am 16.02.2015 um 18:42 schrieb Allin Cottrell:
> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
>> Am 16.02.2015 um 17:58 schrieb Allin Cottrell:
>
>>> The trouble here is that the matrices a and b exist only in the rank 0
>>> process; they need to exist everywhere.
>>>
>>> <hansl>
>>> mpi --np=2
>>> matrix a
>>> matrix b
>>> if $mpirank == 0
>>> b = ones(1000,1)
>>> a = zeros(1000,1)
>>> endif
>>> mpiscatter(&b, byrows)
>>> </hansl>
>>>
>>
>> Hm, ok I understand. My spontaneous reaction would be: "but isn't this
>> what mpiscatter (or mpibroadcast) is supposed to achieve as part of
>> their job?".
>> What's the value added of requiring the pre-existence of the recipient
>> objects?
>
> It's not a question of value added, it's just how MPI works! Remember
> that each "rank" corresponds to a distinct instance of gretlmpi.
> Consider your original code, without the prior declaration of the
> matrices, from the point of view of the rank 1 process: the first line
> rank 1 sees is:
>
> mpiscatter(&b, byrows)
>
> So it's like, "mpiscatter what?? I don't know anything about this
b".
>
Yeah, I actually understood that :-)
But since we're on the gretl list my comment was aimed at the hansl wrapper
implementation: Why can't hansl see the &b in mpiscatter(&b, byrows) and
shout out: "Hey I've seen this b before, it was created in line xyz, and now
everybody's getting it, too." I mean this look-up of existing objects is what
the interpreter does all the time, no?
Not really. If you do the following, which seems analogous to me,
<hansl>
if 0
matrix b = I(3)
endif
print b
</hansl>
you'll get an error since b was never actually defined. And
if $mpirank == 0
is just like "if 0" from the point of view of all MPI processes other
than root.
Allin
7:43 p.m.
Am 16.02.2015 um 19:21 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
> But since we're on the gretl list my comment was aimed at the hansl
> wrapper implementation: Why can't hansl see the &b in mpiscatter(&b,
> byrows) and shout out: "Hey I've seen this b before, it was created in
> line xyz, and now everybody's getting it, too." I mean this look-up of
> existing objects is what the interpreter does all the time, no?
Not really. If you do the following, which seems analogous to me,
<hansl>
if 0
matrix b = I(3)
endif
print b
</hansl>
you'll get an error since b was never actually defined. And
if $mpirank == 0
is just like "if 0" from the point of view of all MPI processes other
than root.
Yes -- but that's where the literal meaning of "broadcast" or
"scatter"
comes in IMO: The whole purpose of these functions is to take something
that doesn't exist in other processes yet and copy it over there. So
it's a function that creates something in the subprocesses. In principle
that could also be written as (with non-existing syntax):
matrix b = mpibroadcast(b[$mpirank==0])
and this would make it completely clear that this creates b in all
"ranks". (I'm not suggesting this syntax change, it's just for the sake
of the argument.) From this point of view I think the empty
pre-declaration could be redundant.
cheers,
sven
10:29 p.m.
On Mon, Feb 16, 2015 at 2:43 PM, Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 16.02.2015 um 19:21 schrieb Allin Cottrell:
> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>
>>
>> But since we're on the gretl list my comment was aimed at the hansl
>> wrapper implementation: Why can't hansl see the &b in mpiscatter(&b,
>> byrows) and shout out: "Hey I've seen this b before, it was created in
>> line xyz, and now everybody's getting it, too." I mean this look-up of
>> existing objects is what the interpreter does all the time, no?
>
> Not really. If you do the following, which seems analogous to me,
>
> <hansl>
> if 0
> matrix b = I(3)
> endif
> print b
> </hansl>
>
> you'll get an error since b was never actually defined. And
>
> if $mpirank == 0
>
> is just like "if 0" from the point of view of all MPI processes other
> than root.
>
Yes -- but that's where the literal meaning of "broadcast" or
"scatter"
comes in IMO: The whole purpose of these functions is to take something
that doesn't exist in other processes yet and copy it over there. So
it's a function that creates something in the subprocesses. In principle
that could also be written as (with non-existing syntax):
matrix b = mpibroadcast(b[$mpirank==0])
and this would make it completely clear that this creates b in all
"ranks". (I'm not suggesting this syntax change, it's just for the
sake
of the argument.) From this point of view I think the empty
pre-declaration could be redundant.
Sorry, but this doesn't really make sense to me. We would have to
institute something complicated that we don't do at present, namely
parsing (but not executing) lines of hansl that are blocked by a false
"if" condition. We'd have to keep a stack of names and types of objects
that don't exist but that might exist in future (if they're subsequently
broadcast or scattered). IMO it's much cleaner just to go with the MPI
paradigm, according to which objects that are to be shared have to be
declared at all ranks.
Allin
10:31 a.m.
Am 16.02.2015 um 23:29 schrieb Cottrell, Allin:
On Mon, Feb 16, 2015 at 2:43 PM, Sven Schreiber
<svetosch(a)gmx.net> wrote:
>
> Yes -- but that's where the literal meaning of "broadcast" or
"scatter"
> comes in IMO: The whole purpose of these functions is to take something
> that doesn't exist in other processes yet and copy it over there. So
> it's a function that creates something in the subprocesses. In principle
> that could also be written as (with non-existing syntax):
>
> matrix b = mpibroadcast(b[$mpirank==0])
>
> and this would make it completely clear that this creates b in all
> "ranks". (I'm not suggesting this syntax change, it's just for the
sake
> of the argument.) From this point of view I think the empty
> pre-declaration could be redundant.
Sorry, but this doesn't really make sense to me. We would have to
institute something complicated that we don't do at present, namely
parsing (but not executing) lines of hansl that are blocked by a false
"if" condition. We'd have to keep a stack of names and types of objects
that don't exist but that might exist in future (if they're subsequently
broadcast or scattered). IMO it's much cleaner just to go with the MPI
paradigm, according to which objects that are to be shared have to be
declared at all ranks.
Maybe I have a misunderstanding here -- how many data copies are there
if you do:
matrix b
if $mpirank == 0
matrix b = {1}
endif
So a bunch of "b" exist in all ranks. And the value of "b" in rank 0
should be one. But what's the value of all those "b"s in the other
ranks, before you do a broadcast or scatter? I would guess they're still
empty because otherwise there wouldn't be a point to do the assignment
only in rank 0. Right?
If that's right, then what mpiscatter or mpibroadcast effectively do is
to _create_ (conceptually) an array of matrices with the same name.
("Array" again in a conceptual sense, don't known what's the internal
structure.) There would be no need to keep track of non-existing objects
even without pre-declaration:
if $mpirank == 0
# creation in rank 0 only:
matrix b = {1}
endif
# creation for all ranks:
# (non-existing syntax to be more explicit,
# but the same goes for just mpibroadcast(&b))
matrix b = mpibroadcast(&b)
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.
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.
thanks,
sven
1:23 p.m.
On Tue, 17 Feb 2015, Sven Schreiber wrote:
Am 16.02.2015 um 23:29 schrieb Cottrell, Allin:
> On Mon, Feb 16, 2015 at 2:43 PM, Sven Schreiber <svetosch(a)gmx.net> wrote:
>>
>> Yes -- but that's where the literal meaning of "broadcast" or
"scatter"
>> comes in IMO: The whole purpose of these functions is to take something
>> that doesn't exist in other processes yet and copy it over there. So
>> it's a function that creates something in the subprocesses. In principle
>> that could also be written as (with non-existing syntax):
>>
>> matrix b = mpibroadcast(b[$mpirank==0])
>>
>> and this would make it completely clear that this creates b in all
>> "ranks". (I'm not suggesting this syntax change, it's just for
the sake
>> of the argument.) From this point of view I think the empty
>> pre-declaration could be redundant.
>
> Sorry, but this doesn't really make sense to me. We would have to
> institute something complicated that we don't do at present, namely
> parsing (but not executing) lines of hansl that are blocked by a false
> "if" condition. We'd have to keep a stack of names and types of
objects
> that don't exist but that might exist in future (if they're subsequently
> broadcast or scattered). IMO it's much cleaner just to go with the MPI
> paradigm, according to which objects that are to be shared have to be
> declared at all ranks.
>
Maybe I have a misunderstanding here -- how many data copies are there if you
do:
matrix b
if $mpirank == 0
matrix b = {1}
endif
So a bunch of "b" exist in all ranks.
I would say, a matrix named "b" exists at each rank. The b at rank 0
contains 1 while the b's at other ranks are empty.
If that's right, then what mpiscatter or mpibroadcast effectively
do is to
_create_ (conceptually) an array of matrices with the same name. ("Array"
again in a conceptual sense, don't known what's the internal structure.)
I would say, the scatter or broadcast transmits the content of a
matrix at the root node, such that the like-named matrices at all
nodes acquire the same content (broadcast) or a portion thereof
(scatter).
There would be no need to keep track of non-existing objects even
without
pre-declaration:
if $mpirank == 0
# creation in rank 0 only:
matrix b = {1}
endif
# creation for all ranks:
# (non-existing syntax to be more explicit,
# but the same goes for just mpibroadcast(&b))
matrix b = mpibroadcast(&b)
The problem is that, in either form, this contravenes existing hansl
semantics. Conceptually, "&b" means the address of b, and if b
doesn't already exist it doesn't have an address. All our functions
that take a matrix pointer argument require that the "pointed to"
matrix has already been declared.
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. The n - 1 copies
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.
If we allow (as we presently do) that the root node doesn't have to
be rank 0 (or not all the time), then each rank would have to peek
at the code specific to all other ranks in case anything that's not
globally declared features in a broadcast or scatter.
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".
Allin
2:32 p.m.
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
3:52 p.m.
On Tue, 17 Feb 2015, Sven Schreiber wrote:
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...
A little more info on MPI, in case it's helpful. MPI provides an
infrastructure that lets you launch n copies of a program on
different cores or different machines, and a mechanism whereby these
processes can communicate with each other (broadcast, scatter and
friends). MPI is not a programming language as such, but it provides
APIs in both C and Fortran. Gretl's implementation rests on the C
API.
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)"?
In principle, rank 0 can send any information you want to the other
processes, but only via broadcast/scatter.
When you do mpibcast() on a matrix in gretl, libgretl first
broadcasts the dimensions, "in the background", so that each process
can allocate space for the content. If that goes OK then the actual
content is broadcast and copied into the memory of each process.
We don't currently support broadcast of string variables but we
could if that seemed useful. In that case rank 0 could send out the
name of a matrix to be received. However, this would generate a
regress, in that you'd then need a pre-existing string variable at
each rank to receive the name (plus string substitution to make use
of it), as in
string mname
if $mpirank == 0
mname = "b"
matrix b = {whatever}
endif
mpibcast(&mname)
if $mpirank > 0
matrix @mname
endif
mpibcast(&@mname)
This would be more cumbersome that just declaring b in all
processes.
Allin
5:39 p.m.
Am 16.02.2015 um 16:54 schrieb Allin Cottrell:
On Mon, 16 Feb 2015, Sven Schreiber wrote:
> Am 16.02.2015 um 14:45 schrieb Allin Cottrell:
>> On Mon, 16 Feb 2015, Sven Schreiber wrote:
>>
>>> Am 16.02.2015 um 09:22 schrieb Riccardo (Jack) Lucchetti:
>
>>>>
>>>> Yes, it should be ok. Is anything broken?
>>>
>>> No (or at least I haven't found out yet), but I think the example is
>>> too sophisticated. I mean, the example is excellent and shouldn't go
>>> away, but IMO there should be something of the "Hello world" type,
>>> much shorter. I will try to produce a minimal example.
>>
>> OK, thanks.
>>
So here's a working attempt, still longer than I wanted though... but
there are lots of comments! Eventually I will check out from which
number T on the speed gain outweighs the overhead.
-sven
<hansl>
# The not-quite-"Hello world" of gretl-mpi
# prepare the common input
T = 100
matrix in = ones(T,1)
# and transfer it
mwrite(in, "in.mat", 1)
mpi --np=2 # can change the num of procs
matrix b, c # must declare for all procs
# get the input data with the root process 0
matrix b = $mpirank == 0 ? mread("in.mat", 1) : b
# divide up the input data
mpiscatter(&b, byrows)
# this is the parallelized operation
matrix c = sin(b) + log(b)
# collect the results
mpireduce(&c, vcat) # vertical stacking
# output in root process
if $mpirank == 0
print c
endif
end mpi
</hansl>
3909
days inactive
3910
days old
20 comments
4 participants
participants (4)
-
Allin Cottrell -
Cottrell, Allin
-
Riccardo (Jack) Lucchetti -
Sven Schreiber