RFC: Using Standard C++ library components in Octave

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Using Standard C++ library components in Octave

Mumit Khan-4
[ I'm not subscribed to this list, so please copy me if appropriate ]

This issue of using more of the standard C++ library has been in the back
of my mind for a while now, and probably a good time to see how JWE and
others feel about replacing Octave's "foundation classes" with C++ library
components.

Octave was written well before the advent of STL and then the standard
C++ library, and like any long-lived C++ projects, it has tons of code
that have somewhat direct equivalents in the new library. This includes
various data structures such as lists, etc as well as algorithms such
as std::sort, std::copy, std::unique, etc.

I believe it will be beneficial in the long run to replace some/most of
Octave's code with equivalent components in the C++ library, if possible.
The only issue I see is with gcc-2.8.x, which used a hacked version of
the original HP STL, but nobody who does C++ should be using 2.8.x
anyway.

I know that for some of my own older code, the executable code size stayed
about the same (this was a surprise, given the templates used), and the
performance actually increased in the process.

Is this something we want to do? If so, it could be a reasonably slow
and incremental process:

1. Make use of the standard algorithms first. liboctave/idx-vector.cc
   for example stands to lose a bit of code if that happens.
2. Replace the data structures -- start with the various list structures
   and go from there.

Regards,
Mumit



Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Dirk Eddelbuettel

> I believe it will be beneficial in the long run to replace some/most of
> Octave's code with equivalent components in the C++ library, if possible.
[..]
> Is this something we want to do?

Yes, I think we should. It will make maintaining, porting, extending, ...
Octave easier in the long run.  Doing it incrementally as you suggested
is probably a good defensive approach.  

Dirk

--
According to the latest figures, 43% of all signatures are totally worthless.  


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Mumit Khan-4
[ I'm not subscribed to this list, so please copy me if appropriate ]

On Tue, 3 Jul 2001, Dirk Eddelbuettel wrote:

> > Is this something we want to do?
>
> Yes, I think we should. It will make maintaining, porting, extending, ...
> Octave easier in the long run.  Doing it incrementally as you suggested
> is probably a good defensive approach.  

That's essentially the motivation for my proposal. As new contributors
come on line, it's much easier to get started if you're using standard
components instead of home brewed ones that lack documentation on the
API.  It's a bit harder sell for Octave, given that it has a rather
cohesive style throughout, thanks to lack of developers other than jwe.
Still ...

I would like hear from other folks as to what they think of the idea,
leaving aside the issue of who and when.

I have had the reality check few times over when it comes to the various
C++ standard library implementations, especially the subset formerly
known as STL, so I understand to some degree the practical issues
involved. I personally don't see any real pitfall here; my answer would
have been very different a few years ago. Of course, all of this assuming
that this is indeed something worthwhile.

Mumit



Reply | Threaded
Open this post in threaded view
|

RFC: Using Standard C++ library components in Octave

John W. Eaton-6
In reply to this post by Mumit Khan-4
On  2-Jul-2001, Mumit Khan <[hidden email]> wrote:

| [ I'm not subscribed to this list, so please copy me if appropriate ]
|
| This issue of using more of the standard C++ library has been in the back
| of my mind for a while now, and probably a good time to see how JWE and
| others feel about replacing Octave's "foundation classes" with C++ library
| components.
|
| Octave was written well before the advent of STL and then the standard
| C++ library, and like any long-lived C++ projects, it has tons of code
| that have somewhat direct equivalents in the new library. This includes
| various data structures such as lists, etc as well as algorithms such
| as std::sort, std::copy, std::unique, etc.
|
| I believe it will be beneficial in the long run to replace some/most of
| Octave's code with equivalent components in the C++ library, if possible.
| The only issue I see is with gcc-2.8.x, which used a hacked version of
| the original HP STL, but nobody who does C++ should be using 2.8.x
| anyway.
|
| I know that for some of my own older code, the executable code size stayed
| about the same (this was a surprise, given the templates used), and the
| performance actually increased in the process.
|
| Is this something we want to do? If so, it could be a reasonably slow
| and incremental process:
|
| 1. Make use of the standard algorithms first. liboctave/idx-vector.cc
|    for example stands to lose a bit of code if that happens.
| 2. Replace the data structures -- start with the various list structures
|    and go from there.

OK, a year and a half has passed and gcc 3.2 is available with an
increasingly standard and complete implementation of the standard C++
library (though many people are still using gcc 2.95.x, with an
incompatible and non-standard library).  Maybe it is time to start
working on this project?

The last time I tried to use the STL containers, I thought I was doing
something quite trivial, but had trouble on some systems with
extrememely long mangled names that the linker then rejected (I think
it was on HP systems, but it could have been on Alpha systems with
Digital Unix, I can't remember for sure).  Have those problems been
solved with gcc 3.2?

I think that the trivial program I was working with was
doc/interpreter/munge-texi.cc, which only uses the non-standard Map
class.  So perhaps we should start by converting that, and making sure
that we can build it on all of the kinds of systems on which we expect
to build Octave.

I would actually like to reverse the order of your list above so that
we replace the data structures first, but if you have a good reason
for choosing the above order, please leet me know what it is.

A step in that direction (without actually replacing the data types)
would be to convert classes that are derived from the container
classes to have the container as a data member.  That way, instead of
inheriting the interface from the container, the interface of the
Octave classes are stated explicitly.  I think that would be a good
first step, and something that I can do without having to first become
an STL expert.  Then it would be easier for an STL expert to convert
the Octave classes that use containers, one at a time and without
causing errors all over the rest of the code.

Comments?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Mumit Khan-4
On Tue, 12 Nov 2002, John W. Eaton wrote:

> OK, a year and a half has passed and gcc 3.2 is available with an
> increasingly standard and complete implementation of the standard C++
> library (though many people are still using gcc 2.95.x, with an
> incompatible and non-standard library).  Maybe it is time to start
> working on this project?

With the state of affairs stabilizing, this is probably a good time as
any.

> The last time I tried to use the STL containers, I thought I was doing
> something quite trivial, but had trouble on some systems with
> extrememely long mangled names that the linker then rejected (I think
> it was on HP systems, but it could have been on Alpha systems with
> Digital Unix, I can't remember for sure).  Have those problems been
> solved with gcc 3.2?

HPUX. It also happened under SunOS and DUX assemblers when debugging was
turned on.  GNU C++ had a tendency of creating ridiculously long symbol
names, something that has been rectified as of 3.0, causing these
problems. This particular problem is fixable with a better mangling
algorithm, but that should not excuse the large body of development
code that still uses fixed sized buffers (this is one of those cases
where GNU dev tools shine over the commercial alternatives).

> I think that the trivial program I was working with was
> doc/interpreter/munge-texi.cc, which only uses the non-standard Map
> class.  So perhaps we should start by converting that, and making sure
> that we can build it on all of the kinds of systems on which we expect
> to build Octave.

I agree, standalone ones are the best ones to start off with.

>
> I would actually like to reverse the order of your list above so that
> we replace the data structures first, but if you have a good reason
> for choosing the above order, please leet me know what it is.

The order was arbitrary, so either way works fine.

> A step in that direction (without actually replacing the data types)
> would be to convert classes that are derived from the container
> classes to have the container as a data member.  That way, instead of
> inheriting the interface from the container, the interface of the
> Octave classes are stated explicitly.  I think that would be a good
> first step, and something that I can do without having to first become
> an STL expert.  Then it would be easier for an STL expert to convert
> the Octave classes that use containers, one at a time and without
> causing errors all over the rest of the code.

The C++ standard library container classes are not designed to be derived
from, so containment is usually the preferred approach. When I converted
a large body of code a year or so ago, I faced essentially the same
problem, and it took a few iterations to get it right (this particular
piece of code, roughly the same size of Octave C++ code, is quite old
-- I first started it with Cfront, then modified it over time just enough
to get it to work with newer compilers).

Regards,
Mumit



Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Paul Kienzle-2
In reply to this post by John W. Eaton-6
On Tue, Nov 12, 2002 at 08:43:41PM -0600, John W. Eaton wrote:

> On  2-Jul-2001, Mumit Khan <[hidden email]> wrote:
>
> | [ I'm not subscribed to this list, so please copy me if appropriate ]
> |
> | This issue of using more of the standard C++ library has been in the back
> | of my mind for a while now, and probably a good time to see how JWE and
> | others feel about replacing Octave's "foundation classes" with C++ library
> | components.
> |
> | Octave was written well before the advent of STL and then the standard
> | C++ library, and like any long-lived C++ projects, it has tons of code
> | that have somewhat direct equivalents in the new library. This includes
> | various data structures such as lists, etc as well as algorithms such
> | as std::sort, std::copy, std::unique, etc.
> |
> | I believe it will be beneficial in the long run to replace some/most of
> | Octave's code with equivalent components in the C++ library, if possible.
> | The only issue I see is with gcc-2.8.x, which used a hacked version of
> | the original HP STL, but nobody who does C++ should be using 2.8.x
> | anyway.
> |
> | I know that for some of my own older code, the executable code size stayed
> | about the same (this was a surprise, given the templates used), and the
> | performance actually increased in the process.
> |
> | Is this something we want to do? If so, it could be a reasonably slow
> | and incremental process:
> |
> | 1. Make use of the standard algorithms first. liboctave/idx-vector.cc
> |    for example stands to lose a bit of code if that happens.
> | 2. Replace the data structures -- start with the various list structures
> |    and go from there.
>
> OK, a year and a half has passed and gcc 3.2 is available with an
> increasingly standard and complete implementation of the standard C++
> library (though many people are still using gcc 2.95.x, with an
> incompatible and non-standard library).  Maybe it is time to start
> working on this project?
>
> The last time I tried to use the STL containers, I thought I was doing
> something quite trivial, but had trouble on some systems with
> extrememely long mangled names that the linker then rejected (I think
> it was on HP systems, but it could have been on Alpha systems with
> Digital Unix, I can't remember for sure).  Have those problems been
> solved with gcc 3.2?
>
> I think that the trivial program I was working with was
> doc/interpreter/munge-texi.cc, which only uses the non-standard Map
> class.  So perhaps we should start by converting that, and making sure
> that we can build it on all of the kinds of systems on which we expect
> to build Octave.
>
> I would actually like to reverse the order of your list above so that
> we replace the data structures first, but if you have a good reason
> for choosing the above order, please leet me know what it is.
>
> A step in that direction (without actually replacing the data types)
> would be to convert classes that are derived from the container
> classes to have the container as a data member.  That way, instead of
> inheriting the interface from the container, the interface of the
> Octave classes are stated explicitly.  I think that would be a good
> first step, and something that I can do without having to first become
> an STL expert.  Then it would be easier for an STL expert to convert
> the Octave classes that use containers, one at a time and without
> causing errors all over the rest of the code.
>
> Comments?

How many things can we use from STL?

If we are replacing octave_value_list, is this also a good time to
change how Octave manages values?  Allocating objects on the stack
and returning them from functions means that Octave is spending a
lot of time in constructors, copy constructors and destructors.  If
instead we were passing around references then much of that could be
avoided.

- Paul


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Greg Troxel
In reply to this post by John W. Eaton-6
I'll throw out a perhaps crazy thought --- which I'm not really
advocating, just suggesting be thought about for a few minutes ---
which is to use glib instead.  Glib is in C, and runs on lots of
places (as the foundation for gtk+, gimp, and Gnome).

Glib has many of the usual list, tree etc. data structures, and an
object-oriented mentality, particularly with glib-2.0.
Glib objects could be contained in a C++ class just as STL objects
could be contained.

There has been talk of integrating guile in the past, and using glib
points out the possibility of using the
guile/guile-gobject/ORBit/bonobo nexus.  It would be cool to have
octave available via CORBA as a Gnome desktop component and therefore
usable as a plugin for other programs.  Making octave a gnome desktop
component would require linking with glib (and many other things), but
wouldn't require that internal data structures be in any particular
format, so these issues are not really coupled.  That said, using glib
would be a slight cultural shift in the gnome-hat direction.

The downside of glib is that it probably changes more often than STL,
but it appears to do so fairly slowly.  I would find requiring glib to
be less of a burden than installing gcc 3.2, although really either is
pretty easy.

        Greg Troxel <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Paul Kienzle-2
On Wed, Nov 13, 2002 at 09:02:13AM -0500, Greg Troxel wrote:
> There has been talk of integrating guile in the past, and using glib
> points out the possibility of using the
> guile/guile-gobject/ORBit/bonobo nexus.  It would be cool to have
> octave available via CORBA as a Gnome desktop component and therefore
> usable as a plugin for other programs.  Making octave a gnome desktop
> component would require linking with glib (and many other things), but
> wouldn't require that internal data structures be in any particular
> format, so these issues are not really coupled.  That said, using glib
> would be a slight cultural shift in the gnome-hat direction.

I'm interested in making an "embeddable" octave which is basically a
headless compute engine so that it can run without the console on Windows.
The same operations would perhaps be useful for writing an octave server
or ORB wrapper.  Would you care to spec out what you would need for a
Gnome corba wrapper?

For what I'm doing with the Tk link, there are a number of things I
need.

* the initialization code must be separated out

* the read-eval-print loop must be turned into a eval string statement

* for me it would be convenient to have separate toplevel namespaces
  which can share global variables --- presumably the namespace would
  be the handle passed to eval

* octave signal handling should not interfere with the application
  signal handling

* octave should be callable from C code, so publish the interface in
  an extern "C" block

* need to do something about input/debug since octave is running
  without stdio

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

Greg Troxel
I think the hardest part is figuring out what the semantics of the
interface should be.  I think many of your list changes are needed
since they reflect making octave usable as a reentrant library rather
than adding CORBA.  Allowing the daemon to initialize itself on
startup making the repl be a procedure call, and allowing for multiple
environments are all needed.

So, a client would call

  Octave::new()

and be returned a CORBA object which is a handle for a new top-level
environment.  Then, there would be calls to evaluate a statement,
returning the result, and probably some way to do something like
'load', but with the file being passed across the interface rather
than read from a file, and a corresponding save call.  This would be
used by programs that store octave files embedded in data files for
e.g. a document.

With CORBA, the servant created in the octave process to instantitate
the interface can contain the namespace ID, so no explicit passing of
namespaces is needed.  The new operation in the server allocates an
object, and the reference returns to the client refers to that object
in the server.  If the using program wants to share a namespace, it
can transmit the CORBA reference to a third program.  (This approach
avoids the issue of "what if one program wrongly executes a call on
another's namespace", although the notion of multiple users in one
octaved daemon process conjures up MLS nightmares very quickly.)
In the GNOME world, security is usually handled by having the daemons
run as the user, and all communication on a mode 700 AF_UNIX socket.

In general the approach for CORBA is the same for other scripting
calls, and will consist of two main tasks in addition to explicit
representation of multiple execution contexts.

  * factoring out I/O to procedure calls (as you discuss), decoupling
    the processing itself from the input and output

  * thinking about data representation.  octave prints matrices in
    a way intended for humans to read.  For a CORBA interface, as
    opposed to a remote GUI, there should be a way to return typed
    data itself, rather than a printed representation.

Signal handling and related issues are probably one of the more
difficult tasks.  CORBA procedure calls are naturally synchronous, and
one is pushed to use threads.  For long-running computations, one
could have an interface "computation_token =
Octave::start_compute(stuff)", a way to then obtain the result or
status, a way to ask for a notification callback, and a way to kill
computations.  This could let someone use a program to request a
computation and come back later to retrieve it, perhaps on a different
desktop session.  This starts down the path of the server being able
to save intermediate state.

For further info, I suggest reading
 http://developer.gnome.org/arch/component/bonobo.html
 http://www.gnome.org/gnome-office/bonobo.shtml

You of course don't need to use bonobo, but I do recommend
understanding it before declining to use it.  In particular, gnumeric
(spreadsheet) uses bonobo to embed guppi, and this is probably the
most similar usage.  Guppi has some octave-like features in support of
plotting.

  http://www.gnome.org/projects/guppi/
  http://www.gnome.org/projects/guppi/features.shtml

Another possibly related effort is GSL, for which guile bindings are
now available:
  http://sources.redhat.com/gsl/
  http://www.nongnu.org/guile-num/
  http://sources.redhat.com/ml/gsl-announce/2002/msg00009.html
I realize that of course GSL was not around when octave started, but
another refactoring rampage would be to use GSL (which can use ATLAS).

I suspect that making octave scriptable from guile in the above sense
would enable near-trivial CORBA-ization via 'guile-gobject', which is
not quite baked but seems to be coming along.  Guile-gobject is guile
bindings for glib/gtk-2.0, and enables writing CORBA client and
servers without having to write any C glue code.

        Greg Troxel <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

John W. Eaton-6
In reply to this post by Mumit Khan-4
On 13-Nov-2002, Mumit Khan <[hidden email]> wrote:

| HPUX. It also happened under SunOS and DUX assemblers when debugging was
| turned on.

OK, I've made the simple modifications to munge-texi.cc so that it
uses STL map.  I compiled with gcc 2.95 and 3.2 on a Linux system and
the mangled names are quite long.  Then I tried with gcc 3.1.1. on a
SunOS system (not my system; it was what they had installed) and the
mangled names were much shorter, even with -g.  Then I also tried with
the Sun WorkShop 6 2000/04/07 C++ 5.1 compiler and that also worked,
with mangled names longer than the g++ names.  So I think we can give
it a try.  If people complain that it doesn't work, we first get them
to try gcc 3.2.  If that fails, I've made it easy to go back to the
old libg++ Map class, at least for now.

| The C++ standard library container classes are not designed to be derived
| from, so containment is usually the preferred approach.

Then the first step will be to reorganize the Octave classes that use
the libg++ container classes, but not replace them with STL containers
(I can work on this part).  Then once that works and the containers
are isolated, we can start replacing the old libg++ stuff as it is
convenient to do so (I will probably need some help with this, since
I'm not very familiar with STL classes and the best way to use them).

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

John W. Eaton-6
In reply to this post by Paul Kienzle-2
On 13-Nov-2002, Paul Kienzle <[hidden email]> wrote:

| How many things can we use from STL?

Octave currently uses list, stack, and map objects.

| If we are replacing octave_value_list, is this also a good time to
| change how Octave manages values?

Maybe.  But octave_value_list is not really a list, it is implemented
using the Array<T> classes.  But it might make sense to do it
differently.

| Allocating objects on the stack
| and returning them from functions means that Octave is spending a
| lot of time in constructors, copy constructors and destructors.  If
| instead we were passing around references then much of that could be
| avoided.

I came across a message from you about this in the last few days (I've
been trying to clean out the backlog of messages/bug reports that I've
accumulated over the past couple of years, in case it wasn't obvious
from the recent traffic on the lists).  I was surprised by the
results you showed because the octave_value and octave_value_list
objects use reference counting and a custom allocator to help speed up
creating and copying.

I'd like to make things faster if we can still do it in a "safe" way.
What I want to avoid is code that uses pointers in a way that means we
are calling new/delete outside of constructors/destructors (seems to
me that is asking for memory leaks and segfaults).  The thing I like
about the current way things are written is that nearly everything can
be passed around as a value and memory management is greatly
simplified.  But reference counting is just a poor-man's garbage
collection scheme, right?  It's simple, but maybe not as good as we
could do.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

JD Cole-2
In reply to this post by Paul Kienzle-2
Paul Kienzle wrote:

>On Wed, Nov 13, 2002 at 09:02:13AM -0500, Greg Troxel wrote:
>  
>
>>There has been talk of integrating guile in the past, and using glib
>>points out the possibility of using the
>>guile/guile-gobject/ORBit/bonobo nexus.  It would be cool to have
>>octave available via CORBA as a Gnome desktop component and therefore
>>usable as a plugin for other programs.  Making octave a gnome desktop
>>component would require linking with glib (and many other things), but
>>wouldn't require that internal data structures be in any particular
>>format, so these issues are not really coupled.  That said, using glib
>>would be a slight cultural shift in the gnome-hat direction.
>>    
>>
>
>I'm interested in making an "embeddable" octave which is basically a
>headless compute engine so that it can run without the console on Windows.
>The same operations would perhaps be useful for writing an octave server
>or ORB wrapper.  Would you care to spec out what you would need for a
>Gnome corba wrapper?
>
>For what I'm doing with the Tk link, there are a number of things I
>need.
>
>* the initialization code must be separated out
>
>* the read-eval-print loop must be turned into a eval string statement
>
>* for me it would be convenient to have separate toplevel namespaces
>  which can share global variables --- presumably the namespace would
>  be the handle passed to eval
>
>* octave signal handling should not interfere with the application
>  signal handling
>
>* octave should be callable from C code, so publish the interface in
>  an extern "C" block
>
>* need to do something about input/debug since octave is running
>  without stdio
>
>Paul Kienzle
>[hidden email]
>
>
>  
>
I'm also interested in developing an "embeddable" version of octave,
however, I would like to use it for a multiprocessor/multicomputer
version. I would like to configure octave with a minimum of display
requirements, perhaps just stream i/o, no termcap or readline libraries.
Another point which JWE and PK have been discussing is the determining
the excution time of code to determine when to interupt. (I have taken a
look at Andy Jocabson's octave-mpi modification (thanks JWE)...but would
like to take it a step further.) Any suggestions as to a starting point?

Best,
-JD



Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

John W. Eaton-6
On 17-Nov-2002, JD Cole <[hidden email]> wrote:

| I have taken a
| look at Andy Jocabson's octave-mpi modification (thanks JWE)...but would
| like to take it a step further.

In what way?

I know that Andy's interface to MPI is fairly simple and limited, but
it is a start.  I'm thinking of integrating it almost as-is (because
it does seem to be useful) and then encouraging whoever is interested
to make a more complete interface to the MPI library, at which point
the type of interface that Andy contributed could probably be
rewritten as a collection of M-files.  I think there has been some
discussion about this kind of interface to MPI in the past, bt I've
never seen any working code -- my apologies if I missed it.

jwe




Reply | Threaded
Open this post in threaded view
|

Re: RFC: Using Standard C++ library components in Octave

JD Cole-2
John W. Eaton wrote:

>On 17-Nov-2002, JD Cole <[hidden email]> wrote:
>
>| I have taken a
>| look at Andy Jocabson's octave-mpi modification (thanks JWE)...but would
>| like to take it a step further.
>
>In what way?
>
>I know that Andy's interface to MPI is fairly simple and limited, but
>it is a start.  I'm thinking of integrating it almost as-is (because
>it does seem to be useful) and then encouraging whoever is interested
>to make a more complete interface to the MPI library, at which point
>the type of interface that Andy contributed could probably be
>rewritten as a collection of M-files.  I think there has been some
>discussion about this kind of interface to MPI in the past, bt I've
>never seen any working code -- my apologies if I missed it.
>
>jwe
>
>
>
>
>  
>
I have started integrating the octave-mpi code into the current latest
CVS checkout, as of a few days ago as a learning tool, when I'm done I
can send you the patches.

For the curious, here's a paper which describes bringing parallelism to
the Matlab environment:
http://citeseer.nj.nec.com/menon97multimatlab.html


JD



Reply | Threaded
Open this post in threaded view
|

parallel octave (was Re: RFC: Using Standard C++ ...)

Paul Kienzle-2
Hayato Fujiwara of Tohoku University, Japan also has an oct-file extension
which allows distributed processing:

        http://www.higuchi.ecei.tohoku.ac.jp/octave/

He does not rely on MPI but instead rolls his own from sockets.  He provides
connect, send, recv, reval, close.

Paul Kienzle
[hidden email]

On Mon, Nov 18, 2002 at 12:35:56AM -0800, JD Cole wrote:

> John W. Eaton wrote:
>
> >On 17-Nov-2002, JD Cole <[hidden email]> wrote:
> >
> >| I have taken a
> >| look at Andy Jocabson's octave-mpi modification (thanks JWE)...but would
> >| like to take it a step further.
> >
> >In what way?
> >
> >I know that Andy's interface to MPI is fairly simple and limited, but
> >it is a start.  I'm thinking of integrating it almost as-is (because
> >it does seem to be useful) and then encouraging whoever is interested
> >to make a more complete interface to the MPI library, at which point
> >the type of interface that Andy contributed could probably be
> >rewritten as a collection of M-files.  I think there has been some
> >discussion about this kind of interface to MPI in the past, bt I've
> >never seen any working code -- my apologies if I missed it.
> >
> >jwe
> >
> >
> >
> >
> >  
> >
> I have started integrating the octave-mpi code into the current latest
> CVS checkout, as of a few days ago as a learning tool, when I'm done I
> can send you the patches.
>
> For the curious, here's a paper which describes bringing parallelism to
> the Matlab environment:
> http://citeseer.nj.nec.com/menon97multimatlab.html
>
>
> JD
>
>