swarm-modeling
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swarm-Modelling] True concurrency?


From: Russell Standish
Subject: Re: [Swarm-Modelling] True concurrency?
Date: Thu, 1 Sep 2005 09:46:15 +1000
User-agent: Mutt/1.4i

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

Attachment: pgpWlBR6ZI0x_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]