||ism

[glen e. p. ropella]

Hey!

I was reading an article in Comp. Science & Eng.  and noticed
some issues that were raised by Berlin and Gabriel in the theme
article "Distributed MEMS: New Challenges for Computation,"
[CS&E Jan-March 1997].

I'm going to quote a paragraph that seems relevant to the coming
 || version of Swarm  (I apologize for quoting so much... but,
though Berlin and Gabriel are talking about smart dust, they could
as easily be talking about modelling decisions in Swarm):

   "Parallel computing has traditionally involved relatively close
temporal synchronization among processes, which tend to be running on
a set of processors located quite near one another.  Distributed
computing, on the other hand, has typically been associated with
processes that may be operating in distant locations, synchronizing
and exchanging results far less frequently.  Distributed MEMS will
require new paradigms that support a high degree of synchronization
over fairly large distances in order to enable applications, such as
sound localization, that require tight synchronizations to correlate
data about events in the environment in real time.

   "Smart dust raises many other questions that pose serious
challenges for computational science.  Should all the smart dust
particles run the same program, as in a SIMD machine, or should
particles specialize and diverge from one another?  How do the
particles synchronize with one another?  How can particles be
dynamically recruited into collaborative groups?  How can
communication be established and maintained in a system where the
physical topology varies over time?  How do we build a global view of
a situation using many small pieces of information that are collected
in different places at different times?  In an energy-limited
programming environment, when is it better to compute (interpolate) a
result, when is it better to communicate with a neighboring particle
to obtain the result, and when is it better to sense the result in the
environment?  How can spatially distinct data streams collected at
different times be combined in an energy-efficient manner?  What are
the abstraction mechanisms that allow easy programming of these
systems?"


1.  I think we need a || methodology that will support *both*
distributed computing, where synchronization may be seldom required,
and || computing, where synchronization may occur very often.  This
seems to imply to me that message passing will become a serious
hindrance in the latter.  And that makes me think that we might not
want to dive glibly into using a system based on MPI.

2.  It's possible that we could use some hybrid of MPI and a virtual
shared memory system.  That might make things a bit easier, since 
we could rely on the shared memory for all the kernel data trading
(which would include the synchronization of Swarms and schedules),
and still use MPI for other object-to-object communication across
hardware.

3.  From the modelling perspective, do any of you *know* for certain
how much synchronization your apps will require?  I.e. do we have 
an estimate of how badly the highly synchronous apps will hit us
and how often we're likely to see apps like that?

4.  Does anybody out there have any experience with pure 
message passing versus distributed shared memory methods?  I.e.
am I fooling myself into thinking that the shared memory method
will be any more efficient than a pure message passing interface?

*Any* opinions on where Swarm should go with this are wanted.

glen
-- 
{glen e. p. ropella <address@hidden> |                                  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================