Re: octave-mpi questions

[JD Cole]

> OK, I have adapted the patches for the current Octave sources.  I
> haven't checked the changes in yet because I have a few questions.
>  
Before you commit those changes, you may want to see if the .oct-file, 
MPI interface I posted a while back will fit Mr. Siegart's needs. I have 
attached them to this e-mail. I had discussed these with Paul as a 
possible addition to Octave-Forge. [See attached tar file] These are 
mearely wrappers to the basic MPI API with the added convenience of 
sending any variable type rather than sending a void* data block. 
(Thanks to Andy's original work on octave-mpi.) Of course, these 
routines could be extended to other functions in the MPI API. (They 
function with existing octave binaries.)

> It seems to me that it would be best for this code to be loaded
> dynamically, and have the mpi library linked only to the dynamically
> loaded .oct file so that users who don't want MPI don't have to pay
> for it (at all) and so we don't have to have two different binaries.
>
> Another way to add the MPI functions to Octave would be to not modify
> Octave's startup procedure at all, but require the user to call some
> kind of mpi_start function that does the initialization and also
> includes the functionality of mpirun (if that is possible -- I suppose
> we will need it to somehow tell the other processes that they should
> perform the MPI startup steps too).  This startup function can also
> call atexit ("mpi_quit") (or similar) to ensure that MPI is stopped
> properly when Octave exits.  The user can also call mpi_quit without
> exiting the main Octave process, then when mpi_quit is called by
> atexit it will do nothing.  The problems I see with this approach are
> the warnings (which seem strange to me) about not doing much before
> calling MPI_Init and passing pointers to the actual argv/argc from the
> C main.  (Surely this is not a requirement, because there are a number
> of add-on packages for Matlab that use MPI and are implemented entirly
> in .m and mex files
The attached code follows your second idea of not modifying the octave 
binary at, and letting the user call MPI functions such as MPI_Init and 
MPI_Finalize. One problem I found with this approach is by allowing the 
user to call MPI_Finalize (), analogous with mpi_quit, is that some MPI 
implementations will not allow the user to call MPI_Init, or 
mpi_startup, again and will cause Octave to prematurely exit, i.e. 
core-dump, when MPI_Init is called a second time. (This specifically 
happens when using the LAM-MPI implementation.) I have added code in the 
mpi_* functions to try to prevent such errors from happening.

> I like the idea of having the flexibility of starting and stopping MPI
> processing on the fly, but I don't know whether that is practical.
>
>  
Are you speaking of, say, allowing a control-C to halt processing on 
other nodes? I'm not sure this can be done. Simply speaking, we want to 
send a UNIX signal to other MPI nodes. Perhaps a "caretaker" daemon 
which sending an interrupt signal upon our request? If the functionality 
were to be built into octave it may require a polling mechenism, which 
would inevitably slow processing down.

-JD

mpi_octave-ss20021218.tar.gz
Description: GNU Zip compressed data