Re: Parallel Question and Swarm Future

[Marcus G. Daniels]

D3> As I understand parallelization (sp? Or even word?) as it pertains to a
D3> Swarm type simulation, is distributed computing. 

There are five potential sources for parallelism in Swarm:

1. Multiple actions scheduled for the same absolute time step at a
   toplevel Swarm merge schedule.  This is fairly common.

2. ActionGroups that are created by hand.

3. Intra-process unsynchronized Swarms.

4. Inter-process unsynchronized Swarms simulations communicating by IPC.

5. Partial order constraints (not yet implemented).

The most fundamental kinds of parallelism that we want to support are
#1 and #2.  We haven't decided on a particular approach, although
POSIX threads and MPI + object migration are two possibilities.

#3 and #5 are nice add-on capabilities once the low-level support
exists.  Resourceful users can do #4 now, but when we finish work on
distributed multilanguage support (starting in January), it will be
easier.

D3> Given that, the collections library needs an overhaul.  This is a
D3> significant problem as all of the scheduling code is based on
D3> collections.  It schedule routines are also very complex and rather
D3> fragile.  It seems to me that if Swarm is going to continue, this is the
D3> next big step. 

There isn't anything really wrong with collections library at the
design level, and the current implementation isn't hurting the
performance of current scheduling feature set.

So although we don't plan an rewrite of the collections library for
the sake of scheduling, we will be adding support for ordered (AVL or
red/black trees) and unordered (hash table) versions of Map and
sibling protocols.  This won't be in the next relase, though.

Rest assured, the collections and activity libraries are receiving
attention, and will continue to do so.

Incidentally, Vladimir has already completed The Dynamic Scheduling
Bug Fix.  The other features to be in 1.4 are object serialization,
HDF5 support for reading and writing large and complex datasets, and
randomized indices (primarily for shuffling ActionGroup execution
order).  Swarm 1.4 will be available early January.

D3> Is it too much to think about a translation to C++? 

>From January to March we will be implementing multilanguage support
with a special emphasis on Java.  *If* C++ is supported, it will only
be because we get it as a side effect of a larger effort. 

We are following the work Cygnus is doing with their GCC-based Java
bytecode compiler, and may help enhance their new runtime and/or the
Objective C runtimes to work together.  Since Cygnus also maintainer
the GNU C++ compiler, there *may* be some effort made to facilitate
interoperability between Java and C++ within GCC. 

Alternatively, Swarm support for C++ might come if we decided to add
Objective C support to a popular CORBA implementation like ILU.  This
is not to imply that CORBA is a substitute for multilanguage support
by the compiler.  Generating CORBA's IDL is easy, and may prove useful
for other system integration reasons, however it probably would be
slow on the first cut as well.

The only constraints we have placed on ourselves so far are to support
Swarm models written in Java, and create and use infrastructure that
generalize to other languages. 

The ETA for Swarm 2.0 is mid-March.  After multilanguage is done, the
universe of options for parallelism (and potential contributors) will
be larger.


                  ==================================
   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.
                  ==================================