MASON-INTEREST-L Archives

December 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Fri, 7 Dec 2007 08:57:55 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
There are three kinds of uses of parallelization here that I'd like  
to disambiguate:

0  Parallelizing an experiment within a single machine.

1. Parallelizing a single experiment by spreading it across multiple  
machines that work together.  This  commonly involves one or both of  
the following tasks.

	1.a Distribute the *space* of the world across multiple machines
	    because it's so big in memory
	1.b Distribute the *agents* of the world because their
	    computational cost is too large

2. Using multiple machines to do multiple experiments, one experiment  
per machine.


#0 is trivial.

For #2, shell scripts and rsh do just fine for us; indeed use of PVM/ 
MPI etc., is just way too heavyweight, particularly since Java and  
MPI don't play well together still.  #2 is also very cleanly done on  
grid computing solutions.  If anyone's interested, there's a company  
in my area (Parabon) which negotiates to borrow excess cycles on  
organizations' PCs and then sells this time with a Java-only piece of  
grid computing software.  For a large NASA project they've adapted my  
ECJ code to this system and I'm sure would be interested in tasks you  
might have in MASON.  Give 'em a call (parabon.com).

For #1, I'm very interested in knowing how people are adapting MASON  
(or RePast) to distribute their experiment.  Do you have 1.a as a  
need?  1.b?  How are you going about hacking MASON etc. to do it?

The reason I ask is that one of our grants may push us to look into  
creating a version of MASON which does #1 cleanly.  Note that MASON  
was specifically designed for #2, and indeed *good*, efficient  
architectures are very different between #1 designs and #2 designs.   
So we're going to have to think about what kinds new data structures  
will we need.  Probably at least we'll need a distributed schedule  
sync device, a way for agents to migrate, and several mechanisms for  
distributing space.  It's a lot of overhead.

I'm interested that some have mentioned RePast.  RePast etc. weren't  
designed for #1 *or* #2.  I know people have been hacking  
distribution onto RePast, and am interested in how they overcame the  
issue of the schedule containing single-machine Java events (repaints  
etc.).  It might help inform us when we get to working on this.

Sean

ATOM RSS1 RSS2