Re: OpenMPI vs. Octave 2.9.x

[Javier Fernández]

Hi all,

Michael Creel wrote:

> David Bateman wrote:
>
> > Michael Creel wrote:
> >
> > > David Bateman wrote:
> > >
> > > > Marius Schamschula wrote:
> > > >
> > > > > ...
> > > > > I used to build Octave 2.1.x with and w/o lam. I have since switched
> > > > > to OpenMPI. After my standard build, I just tried building Octave 
> > > > > with
> > > > > ...
> > > > > Am I safe to assume that there is no current MPI support?
Several different issues here. WRT the switch, we already talked about it
http://velveeta.che.wisc.edu/octave/lists/help-octave/2005/4309
We were not corrected, so I think it's safe to assume the 
--with[out]-mpi switch was void. There is no autoconfigure code for it? 
Well, that seems to corroborate it.

WRT OpenMPI, I have tried to make MPITB  work with it, but I have had 
problems with it in my clusters and I get no response from the OMPI team.
http://www.open-mpi.org/community/lists/users/2006/04/1094.php
http://www.open-mpi.org/community/lists/users/2006/04/1131.php
I will never thank Jeff Squyres enough for his thorough support which 
allowed me to get the first MPITB working. He asked me "why did you 
choose LAM?" I replied "support".

WRT MPITB, it's still not ported to 2.9.9. I'm finishing some pending 
work, and soon I'll be working on it. I'll probably start to make a lot 
of questions on the list. There are new sparse types, aren't there? On 
the other side, I'm not sure MPITB is the "official" MPI for Octave, 
though I'd like it was considered so. I found this presentation from the 
Gelato people (see the title and last slide)
http://www.gelato.org/pdf/apr2006/gelato_ICE06apr_octave_krishnamurthy_osc.pdf

Impressive. Intimidating. I'll try my best and strive to make users feel 
comfortable with MPITB. Apologies for not replying to your first post, 
but I was not certain you were talking about MPITB.

> > > > In octave itself there isn't MPI support, but you should look at
> > > >
> > > > http://atc.ugr.es/javier-bin/mpitb
> > > >
> > > > I'm not sure its ported to 2.9.x yet though..
> > > >
> > > > D.
Exactly. Thanks for the plug. I'll soon be working (and asking for help 
:-) on it.

> > > I for one have started holding my breath. M.
Thanks for your patience and good advices, Michael. I'm in debt with you.

> > Why not make this as a patch against 2.9.x? John for a long while had
> > MPI as one of his to do for 3.0 and so I'm sure he'd consider it if it
> > was ever proposed as a patch..
> >
> > D.
I think JWE preferred by and far something that wouldn't require 
patching Octave. There was a lot of hard discussion about MPI before I 
joined the list and I'm glad I had not chance to participate... I might 
have babbled some unfortunate remark and get flamed and burned... 
sometimes I'm flamed even when my remarks are completely reasonable... I 
always fear about my (lack of) English language performance :-|

But back to the point, I really think JWE preferred the external package 
solution. I still have to learn how to autoconfigure and package MPITB 
with the new packaging system. I'd be glad if MPITB served as the basis 
for more developments. In fact, I'd like to be invited to cooperate in 
such developments... but I thought that was not the preferred 
solution... and I got scared after the last flame war.

> ... MPITB code is GPL'd, though. The source code all lives in a single 
> directory. It compiles to a bunch of .oct files that are bindings to 
> the LAM-MPI functions. I think someone with reasonably good knowledge 
> of C and Octave's internals would have little trouble with the job.
>
> Michael


Just as a suggestion, a piece of code that would make MPITB maintenance 
a kid's game would be a routine for "serializing" Octave datatypes. A 
routine that returned for each (supported-type) variable, a pointer to 
its starting memory location and a size counter... Hmm, right, and a 
description of pointer's type. For more complex types, it might return a 
series of type/pointer/counter triplets which would allow data 
reconstruction on the remote side... Hmm, right again, this time the 
first type descriptor would implicitly describe remaining types, so only 
the first type descriptor would be required. In other words, it would do 
the work done by MPI_Pack.cc in MPITB. The method could be called 
"serialize()" and added to Octave types willing to be supported under MPITB.

It was just a suggestion. It can be easily ignored, no need to discuss 
about it. Michael's idea also serves the same purpose: saving the 
update-bottleneck: me :-) Now, seriously, I'll be updating to 2.9.9 soon.

-javier