swarm-modeling
[Top][All Lists]
Advanced

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

Re: The Swarm space (was RePast (another agent toolkit) released)


From: Miles Parker
Subject: Re: The Swarm space (was RePast (another agent toolkit) released)
Date: Wed, 02 Feb 2000 12:01:22 -0500

>>As we all try to be as unbiased as possible: are there comparisons,
speedwise, using the same model and different languages, or different
agent tools, respectively?  Would be interesting to look at Starlogo, 
too.

In general, I think we're all basically in the same ballpark, except perhaps 
for StarLogo, which I haven't really compared. Of course, the Java front-end to 
Swarm is for the moment the slowest of the bunch, for obvious reasons. What 
differneces there are more often than not come down to implementation details, 
and optimizations that one model can take advantage of where another cannot. 
So, for example, just by informal observation, my sugarscape model runs roughly 
200-300% faster than the Swarm version, whereas my heatbugs implementation runs 
80-90% as fast. This frankly is me as proud father putting Ascape in the best 
possible light - -  the sugarscape model is an extreme example that takes 
advantage of a number of Ascape optimizations. And these optimizations are 
probably more likely to be relevant in the kind of abstract models we've been 
doing in the social and economic sciences. _Most models will probably be 
roughly similar._ And prob. if were were running on a Linux box with an open 
source vm, and Swarm wasn't running under the Cygnus layer, Swarm would do 
better.

For the most part, these runs are pretty graphics bound, and since Java's weak 
point to some extent is still graphics, this is prob. where any perforance hit 
comes in. Computationally, I haven't done any real comparisons. My models run 
_much_ faster (typically by multiple orders of magnitude) when the (run-time 
pluggable) graphical views are removed, but I'm sure the same is true of the 
others. Our style is typically to do the visualization of the model in cases 
where performance isn't that big a factor (in fact, somtimes we might need to 
slow things down..) and then run large paramater sweeps and such w/ the graphic 
views removed. But our models tend to be relativly small. While performance is 
an issue here, it is not as important IMNSHO as other things..and in any case 
needs to be looked at in the context of other hardware and software issues.

So anyway, I don't mean to suggest that I'm blase about performance (in fact, I 
spend far to much time noodling around w/ performace then I probably should..) 
..I do think that optimizations that we can make in Ascape due to higher level 
abstraction will sometimes be compelling, but balanced against that Swarm can 
sometimes be a little closer to the metal. But basically, differences between 
different vms, runtime environments, machines, etc.. seem to overwhelm any 
'inherent' differences. It might be interesting to do some formal benchmarking, 
but my sense is that it wouldn't be that valuable, and would probably end up 
being quite misleading. I think comparisions should probably be made for the 
most part based on other factors. Really, you shouldn't be 'comparing' so much 
as picking the right tool for the job; there are major differences in focus and 
capabilities..and the two (now three) can be seen as quite complementary.

-Miles

Oh, and I'm obviously biased so take all the above with a wee grain of salt...



Miles T. Parker
Software Engineer
The Brookings Institution  1775 Mass. Ave. NW  Washington, DC  20036
http://www.brook.edu/es/dynamics/models/ascape
mailto:address@hidden  voice 202.797.6136  fax 202.797.6319



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================


reply via email to

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