Re: parallelism

[Marcus G. Daniels]

>>>>> "RS" == Ralf Stephan <address@hidden> writes:

MD> The goal of high-level parallelism for Swarm requires tools for
MD> quantitatively determining which sets of agents are
MD> logically/effectively independent and which are interdependent.

RS> Um, wouldn't a [ActionGroup setDefaultOrder: Randomized] suffice
RS> to tell the system which ones are mutually independent?

Sure, to the extent one can "tell" aggregates of components of an
agent-based model to do something, those kinds of features are important.

Since the larger goal of modeling is to gain a better understanding of
a whole system, i.e. how all the pieces fit together and interact in
different contexts, and since agent-based simulation is a way to throw
together lots of pieces, it can happen that localized-but-collective
(and exploitable) behaviors emerge.  In heatbugs, say, the bugs
distribute spatially into groups to maintain their individual heat
preferences.  Although these spatial are deterministic, the clusters
come from the simulation, i.e. by the concurrent application of
recursive functions with shared parameters.  We don't "tell" Swarm in
an direct way how and where to form these heat clusters, they just end
up occuring.

So by the "high-level parallelism" I'm talking about tools that aid
modelers in gaining some intuition about the emergent concurrency in
the model, such that the modeler may change the model description
itself, or that tools that use this information can optimize the physical
distribution of agent state (e.g. what RAM the agent lives in), and
the medium by which agents communication (e.g. over inter-process
communication or not).

Even if we did have a multithread version of the logical concurrency
model now, I don't think it would help most Swarm users achieve major
performance gains.  I believe this is so because most Swarm users
don't seem to make serious use of nested activity structures, and
until you do you don't get the dense population of concurrent
actions on merge schedules (evident, exploitable concurrency). 

I think one reason Swarm users don't make complex activity hierarchies
is because it is hard to get a feeling for what is going on, and thus
feel confident in the results (as a programmer I call it "bits between
my toes").  However, if we had better visualization of activity
hierarchies (relative event flow, relative action cost, etc.), then I
think modelers would use more of these features.

Of course, Occam's razor suggests the models should be simple, and
simple (flat) models won't require complex activity hierarchies (and
thus the logical concurrency model in Swarm has less structure from
which to extract concurrency).  These modelers need a different kind
of tool in order to get parallelism, e.g. tools for hitting a model
over and over again with different parameters in parallel on different
machines -- tools like Drone.


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