Re: Scheduling

[Rick Riolo]

The speed of Starlogo vs Swarm in GUI mode may also be because it does
special things to make the graphics go fast.
That is, if you could run the two models in batchmode,
there might not be much difference.
(I can't recall...can you run starlogo in batch mode?)

I don't know if its still true, but in the early starlogo's
seemed to go skip software layers and go as directly to hardware
as they could for its graphics...the result being,for instance, you
could not run it very well (if at all) on mac emulators (eg under HPUX).

- r

Rick Riolo                           address@hidden
Center for Study of Complex Systems (CSCS)
4477 Randall Lab
University of Michigan         Ann Arbor MI 48109-1120
Phone: 734 763 3323                  Fax: 734 763 9267
http://www.pscs.umich.edu/PEOPLE/rlr-home.html

On 27 Mar 2001, Marcus G. Daniels wrote:

> Date: 27 Mar 2001 11:52:55 -0800
> From: Marcus G. Daniels <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: Re: Scheduling
>
> >>>>> "RL" == Rob Leclerc <Rob> writes:
>
> RL> As it stands it *appears* that my implementation is quite a bit
> RL> slower than that in StarLogo based similar grid sizes.?
>
> That's quite possible.  StarLogo is coded in a very delicate way to be
> fast for grid-oriented things.
>
> RL> Part of my implementation is that I have each agent schedule their
> RL> own activities as opposed to having the model itself activating those
> RL> activities.? I am wondering?how much of a performance hit I would
> RL> get from this or if there might be some other intrinsic reasons
> RL> why this would be slower.?
>
> The main thing you will get a performance hit from is dynamic insertion of new
> events.  There should not be a lot of overhead from adding depth to models
> or having agents schedule their own actions.
>
> There's a lot that can be done to speed-up models, but the first step is
> to get profiling information.  (e.g. jdkswarm -Xprof)
>
> Some of the options are:
>
>   0) Algorithmic optimizations -- profiling makes these obvious
>
>   1) Use language-specific homogeneous ForEach FActions -- that
>      eliminates method dispatch costs and cross language lookups.
>
>   2) Likewise, schedule simple actions with language-specific `FActions'.
>
>   3) Identify places where cross languages calls are expensive and
>      substitute pure Java code.  Or, even better, contribute features to Swarm
>      so that they run in fast chunks for native-code performance.
>
>   4) Use the GNU Java compiler, gcj, to compile the model and Swarm
>      stubs down to native code.  I recently submitted changes to GCJ
>      to make this work.  See the address@hidden mailing list
>      archives if you want to fool around with it.  The result of this
>      is you get a simple executable.  (Unlike what I talked about at
>      SwarmFest last year this doesn't involve a JVM at all.)
>
>      The model I'm working on now had about a 1.3 factor speedup without any
>      other changes.  Also, the quality of profiling information from this
>      is much better than from JVMs, since it goes all the way down
>      through Java runtime support, Swarm itself, and system C libraries.
>
> One of these days I'll add a feature to store references to Swarm-side
> native objects *in* Java objects, but that will require subclassing
> agents from SwarmObject.  That would give a factor of two or speed-up
> for many models, especially those coded in naive ways..
>
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
>
>


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.