MASON-INTEREST-L Archives

August 2009

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:
Date:
Mon, 31 Aug 2009 18:37:46 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
No sweat!

I think you'll find a lot of places where MASON has to strike a balance 
between Java efficiency and traditional design.  We somewhat more often 
come down on the side of Java efficiency, particularly in the core, 
because we're often running MASON on back-end server machines and trying 
to squeeze every drop of blood from it that we can get.  That's why you 
see things like: no use of generics; our own replacement classes for 
certain common Java classes; a distinct aversion to calling objects cast 
into interfaces (which eliminates the ability to do method inlining); 
and so on.  For one big project, one of my students is presently 
cramming 80 million agents into it (and that's not easy!).  I tried hard 
to keep things as obvious for Java coders as we can, but doing so while 
staying maximally efficient is sometimes not trivial.

Sean

Stuart Rossiter wrote:
> Sean,
> 
>    OK, nice answer -- thanks (esp. since it is a side issue). Yes, a
> minor memory hit for speed over many iterations makes perfect sense,
> esp. for visualisations where this is an "optional add-on" to the core
> model.
> 
> Apologies if the original post came across as a "coding lesson". Wasn't
> meant to be: the details just kind of reflected my thought processes in
> thinking about the code alternatives (which were slightly more subtle
> than I'd expected...). I'd be the first to admit that I sometimes get
> hung up on formal OO design principles, instead of the run-time reality :-)
> 
> Regards,
> Stuart

ATOM RSS1 RSS2