Re: Process communication with Guile

[Nicolas Neuss <Nicolas.Neuss@IWR.Uni-Heidelberg.De>]

> Cc: guile@cygnus.com
> From: Jim Blandy <jimb@red-bean.com>
> Date: 16 Jul 1998 00:11:15 -0400
> 
> 
> > The problems I am interested in (solving of partial differential
> > equations) usually can be decomposed in such a way that a rather small
> > set of basic operations operating on large amounts of data are
> > combined to more complicated constructs.  This seems to be a perfect
> > place for using Guile as control language.  But since the interpreter
> > is quite large I would prefer to do it in such a way, that Guile is
> > sort of a client process to a server process written in C or C++ which
> > does the hard work.  This construction would also allow to execute the
> > client and server on different machines which might be very useful.
> 
> 
> I think your system would be cleaner if Guile and your primitives were
> in the same process.  The protocols for communicating between
> processes like this can be a real distraction.
> 
> Is Guile's size the only reason you're considering this?  I think that
> could be a fine reason, I'm just interested in why people are making
> the choices they do.
> 

In some sense it's not the only reason.  First, something about the
context: since about 7 years I am member of a group working on an
adaptive, parallelized code for partial differential equations.  In
1992, I have written a small interpreter for it, one of our future
tasks is to replace it by something more powerful.  I think that an
own development is not very sensible, therefore I am looking for
suitable candidates for such a scripting language.  The client/server
idea is mine, but I am not extremely fanactic about it (the other
members of our group probably even less), so it may well be that it
will remain a private experiment.  In my opinion, it has the following
advantages:

1. It enforces modularity at this point.  Of course, the disadvantage
   is, that one cannot shift tasks easily between scripting
   language and C/C++.  But on the other hand, for our application
   there is a clear line between time-consuming operations on
   grids/matrices and the administrative ones.

2. It allows easy passage to another scripting language.  At the
   moment this is my private experiment, its results will have to be
   discussed with colleagues, and I am not sure what they think
   about Scheme as scripting language (I like it, but I want to
   compare it also to Python, about which I learned recently.).

3. Perhaps my machine is too slow, but I don't like the 5-10 seconds
   linking time which I have for our application at the moment.  I
   guess linking with Guile would mean the same since the library is
   about the same size.  (I don't like several seconds startup time
   for Guile, either, but in the client/server setting this would only
   occur at startup ---even if the server should have been changed---,
   and as much as I understood, people are working on this).

4. Our code is parallelized for MIMD architectures.  I am not working
   on parallelization, but I could imagine a setting useful in which a
   large master program (like Guile with some extensions) would direct
   small ones on the nodes.

Best regards,

Nicolas Neuss.