Re: parallelism

[glen e. p. ropella]

At 02:18 PM 3/29/00 +0200, you wrote:
> I'd bite on that.  What do you have in mind?  Some sort of log window?
> If it can be done with GTK, I'd bite.

I don't see why it couldn't be done with GTK.  Some of the things
we've been discussing are perfect for harnessing some of the research
in algorithm and process animation.  So, the first baby steps would
be something like a text-based log that reports on the observables
specified by the user.  Unless a compact report form can be derived,
however, this isn't very useful.

So, we should develop some kinds of "data reduction" tools to
go along with the logging functionality that parses the logs and
gives a variety of reports, again specifiable by the user.  Examples
of where this kind of thing is being done is provided by the Java
Developer Connection:
http://developer.java.sun.com/developer/technicalArticles/GUI/perfanal/

And there are a number of other efforts in this regard.

The next step will probably be to automate for our users software
metrics like the ones I showed at SwarmFest.  Simple, quick,
metrics that give the user a meta-level idea of what she's just
done.  If we're really ambitious, this could expand out into
fancy metrics like fan-in, fan-out, cohesion, coupling, cyclomatic
complexity, and things like star diagrams.  I doubt we'll take
it that far, though.

Then, the next step would be to combine these first two efforts
into a set of tools that does both logging of the process as it
runs and automated metrics to provide measures of concurrency.
With the current state of the Swarm implementation, this amounts
to little more than a schedule browser/animator.  So, the next
step would be to install threads underneath the Activity library.
Make sure we can handle multi-threaded, single processor, models.
Then move up to something like mosix or another parallel
architecture.

GTK could help immensely (as would other gui tools like Java2/3D,
especially if they're designed to run in an "off-line" way and
either attached to a Swarm process or used as a data reduction
post-Swarm analysis tools) with the visualization of this type
of data.  The most important thing to do on this path is to
begin canvassing the software engineering community for tools
that are already being developed along these lines.  If those
tools (hopefully, free software in the FSF sense) are available,
then we can continue with our integrationist approach and don't
have to do it all ourselves.

That said, I'd like to point out that much of the work that
has already gone into the various sub-tasks that fall under
the heading of "parallelism" very much need to be considered
in this process.  The work that's been done on things like Drone,
ad-hoc Perl scripting, ExperimentSwarms, MPI, etc. are all
particular instances that can enlighten us on our trek toward
our goal (of completely observable and, hopefully, manipulable,
synthetic modeling with a parallel sub-structure).  This is
collaborative research in-process.  And a hearty thanks to those
who have contributed by creating these tools.

glen

--
glen e. p. ropella =><= The front line is everywhere. Hail Eris!
Home: http://forager.swarm.com/~gepr              (505) 424-0448
Work: http://www.swarm.com                        (505) 995-0818


                 ==================================
  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.
                 ==================================