RE: [Swarm-Modelling] True concurrency?

[North, Michael]

Yes, this is true.  Models that have "thick" agents (i.e. agents with
behaviors involving long running computations) are much better
candidates than models with "thin" agents.  Thin agent models usually
require the aggregation approach you outline below to be efficiently
distributed on clusters.

Mike

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
On
> Behalf Of Russell Standish
> Sent: Wednesday, August 31, 2005 6:46 PM
> To: Swarm Modelling
> Subject: Re: [Swarm-Modelling] True concurrency?
> 
> My experience of thread based programming (OpenMP technology in the
> main), is that is essential not to have too fine a granularity on your
> computations. It would only make sense to schedule individual agents
> for independent execution if the agents are computationally complex.
> 
> More likely (for most ABM), you will need to aggregate your agents in
> some manner, so that you have fewer, larger entities to schedule. This
> could be domain decomposition, for example, if the model is
> geographically based.
> 
> The most promising programming model I've come across is the one we
> use in EcoLab, ie agents distributed across a graph. The graph could
> indicate relationships between agents, or it could indicate
> geographical neighbourhoods in the domain decomposition example. The
> good thing about a graph is that it can be automatically partitioned
> into optimal chunks for parallel scheduling using standard graph
> partitioning algorithms.
> 
> Cheers
> 
> On Wed, Aug 31, 2005 at 02:49:14PM -0500, North, Michael wrote:
> >
> > As an extra observation, it is possible to use Repast's
(shared-memory)
> > multiprocessing features in distributed memory situations.  However,
> > this requires extra work on the part of model developers.  For
example,
> > agents can be distributed to different computers (independently of
> > Repast) using tools such as ProActive
> > (http://www-sop.inria.fr/oasis/ProActive/) or raw Java RMI.  Once
the
> > agents are distributed, Repast duration-based multithreaded
scheduling
> > can automatically spawn threads of control to the agents since tools
> > such as ProActive and RMI make the distributed locations of the
agents
> > transparent to Repast.  Of course, this requires work and
computational
> > sophistication on the part of the model developers.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: address@hidden
[mailto:address@hidden
> > On
> > > Behalf Of North, Michael
> > > Sent: Wednesday, August 31, 2005 2:33 PM
> > > To: Swarm Modelling
> > > Subject: RE: [Swarm-Modelling] True concurrency?
> > >
> > > Marcus:
> > >
> > > Good point!  As you correctly observe, Repast requires a true
> > > shared-memory multiprocessor or automatic kernel support for
migration
> > > of threads.  True shared-memory multiprocessors are common, at
least
> > for
> > > relatively small numbers of CPUS.  Automatic kernel support for
> > > migration of threads doesn't really exist.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: address@hidden
> > [mailto:address@hidden
> > > On
> > > > Behalf Of Marcus G. Daniels
> > > > Sent: Wednesday, August 31, 2005 2:15 PM
> > > > To: Swarm Modelling
> > > > Subject: Re: [Swarm-Modelling] True concurrency?
> > > >
> > > > North, Michael wrote:
> > > > >
> > > > > If you have multiple CPUs available then the tasks will
execute in
> > > > > true parallel form on multiple CPUs.  The Repast scheduler
uses
> > > thread
> > > > > pooling to make this efficient.
> > > > >
> > > > Thread polling still means you need a true shared-memory
> > > multiprocessor,
> > > > and not an ordinary cluster..  (Or automatic kernel support for
> > > > migration of threads over a Infiniband cluster interconnect or
> > similar
> > > > -- which unfortunately doesn't really exist.)
> > > >
> > > > [which is not to diminish the feature, just so people don't jump
to
> > > > conclusions!]
> > > > _______________________________________________
> > > > Modelling mailing list
> > > > address@hidden
> > > > http://www.swarm.org/mailman/listinfo/modelling
> > >
> > >
> > > _______________________________________________
> > > Modelling mailing list
> > > address@hidden
> > > http://www.swarm.org/mailman/listinfo/modelling
> >
> >
> > _______________________________________________
> > Modelling mailing list
> > address@hidden
> > http://www.swarm.org/mailman/listinfo/modelling
> 
> --
> *PS: A number of people ask me about the attachment to my email, which
> is of type "application/pgp-signature". Don't worry, it is not a
> virus. It is an electronic signature, that may be used to verify this
> email came from me if you have PGP or GPG installed. Otherwise, you
> may safely ignore this attachment.
> 
>
------------------------------------------------------------------------
--
> --
> A/Prof Russell Standish                  Phone 8308 3119 (mobile)
> Mathematics                                  0425 253119 (")
> UNSW SYDNEY 2052                       address@hidden
> Australia
> http://parallel.hpc.unsw.edu.au/rks
>             International prefix  +612, Interstate prefix 02
>
------------------------------------------------------------------------
--
> --