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