MASON-INTEREST-L Archives

November 2011

MASON-INTEREST-L@LISTSERV.GMU.EDU

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

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

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 3 Nov 2011 22:57:37 -0400
MIME-version:
1.0 (Apple Message framework v1084)
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-type:
text/plain; charset=us-ascii
Subject:
From:
Sean Luke <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
8bit
Parts/Attachments:
text/plain (51 lines)
On Nov 3, 2011, at 5:24 PM, Steven Saul wrote:

> Sorry to bother you with this, but I had a quick question regarding the
> Schedule.  A while ago (back in March) you sent around a revised version
> of the Schedule (called Schedule2.java, see attached) that you were
> thinking might make some people's simulations run a little faster that
> have larger numbers of agents.  I was thinking of giving it a try as my
> simulation represents five species of fish and two fishing fleets on the
> Gulf coast of Florida (about 8 million agents).  When I dumped the file
> into MASON 13, however, I got a syntax error on line 42 (which says
> super.clear();) and when I dump it into MASON 16, I get a syntax error on
> line 33 (which says super.pushToAfterSimulation();).  It can't seem to be
> able to find or over-ride these functions in the original schedule.  Any
> quick fixes?  Also, have people had much success speeding up their
> simulation using this class?  Mine is multi-threaded and currently takes
> about 9 hours on a 64 bit windows 7 machine that has intel's i7 processor
> and 16G of memory (which I'm not complaining about given the number of
> agents and calculations).  Once I clean up the code that does fish
> recruitment I should be able to cut this time down a little more.

It turned out that the alternative schedule version I provided wasn't worthwhile:
the current schedule version in MASON is faster.

There are lots of things that can cause slowdowns in simulations.  The schedule
is only one and it's often not an important one.  Oftentimes other more important
things are badly tuned data structures for the continuous or sparse grids, various
algorithmic decisions in your agents themselves, and so on.

Have you tried profiling your simulation?  You can do it on one of two ways:

1. Run the simulation (I suggest doing so without a GUI) as:

	java -Xprof ... 

When the simulation terminates (or if quit it early) it'll dump a listing of the top
methods being called in the simulation, sorted by how long each method takes.

2. In NetBeans you can run a similar profiler and get a similar analysis.  Maybe in
Eclipse too but it wasn't available up till recently.

You can use the profile report to determine where you need to concentrate your optimization
efforts.  If the profile is showing that a large portion of your time is spent in certain
schedule methods then I can help you reconsider a different calendar queue instead of
the general-purpose heap used in the Schedule.  With 8 million agents it may be of value
to do so anyway.  But I'd first see if optimizing the Schedule would even be worthwhile,
or if something else is taking up all your time.

Send me your profile report, I'd be interested in what it says.

Sean

ATOM RSS1 RSS2