Re: SMP support?

[glen e. p. ropella]

At 09:21 AM 3/21/00 -0800, you wrote:
> DS> What is the current thinking about parallelization and XML, for
> DS> instance?
>
> Unless someone wants to fund us specifically to do parallelization, it
> won't be an immediate priority.  There are too many modeling and
> usability issues to be resolved, first.


What this means is that "to do parallelism correctly", we have to
develop a coherent mechanism for helping the user/modeler find out
what a process is doing.  So, we're working on developing a cohesive,
generic, tool-set to help in taking data off of a model.  The
requirements for such a tool-set are (so far):
1. To provide relevant information for any model or all models.  (i.e.
the tool-set should say something useful regardless of whether your
using it on heatbugs or on ASM or on any other model)
2. To provide general programming and software measures for any
of the various languages we support.
3. To provide concurrency measures and/or a complete characterization
of the static and dynamic structure of the hierarchical scheduling
machinery (possibly including new specification languages like XML or
graphical programming).
4. To provide measures for the executable binary and measures for
the machine as it runs the process.
5. To provide parallel process tracing for models that use multiple
processors and/or machines.  (e.g. like watching a visualization of
a partitioned space or watching agents move between machines)

And I'm sure we'll come up with more high level requirements.  Then
these requirements need to be propagated down to an implementation
level.

This is a hard problem.  Many people don't see it as necessary and
run off and parallelize their programs without giving thought to
how they're going to *verify* their program ('verify' meaning ensure
that it's doing what it's supposed to be doing).  This is, in my
opinion, running off half-cocked.  Most people don't even do the
most basic of analysis on their running code, like profiling, much
less spend time doing proper verification (which is a necessary
part of simulation).

Parallelism is a sledgehammer.  And it's often not proper to use a
sledgehammer.  So, in cases where a user doesn't know whether or
not he needs parallelism, but thinks about it alot because he reads
of applications where it is used to alleged good effect, what the
SDG wants to do is cure the disease, rather than treating the
symptoms.  We want to put the ability to discern whether or not
parallelism (or any other computational tool or resource) is
warranted by providing a tool-set that tells you what your model
is doing.

That said, it should be understood that parallelizing an application
of any kind is always a one-off exercise.  There is no such thing
as "generic" parallelism.  If you have a hard problem, meaning one
that seemingly can only be solved with brute force or a full dynamical
expression of a mechanism, then where multiple instructions and
multiple data apply will be unique for that problem.  This presents
an interesting circumstance for a package like Swarm, that has a generic
concurrency model (of course, it's not completely generic; but, it
covers a large portion of the synthetic modeling space).  It means
that there are several types of parallelism that we have to consider.
Our approach up until now is that we leave it all up to the modeler
to decide when and how to parallelize their model.  (And some people
*have* parallelized their models in various different ways.  There's
nothing stopping a Swarm modeler from parallelizing their model today,
with the current Swarm.)

Asking the SDG to "do parallelization" for all of the Swarm models
out there, in a generic way, is asking *alot* of the SDG.  In fact,
I might argue that it's an impossible task.  So, what we need is a
way to determine what parts of "parallelism" are of the biggest
concern to a prototypical Swarm user, then put mechanisms in place
to facilitate that user.

And to do that, we need tools that quantify observables taken off
of models and the infrastructure upon which those models run.

So, this next item on the agenda, which I call "process tracing",
is, in fact, a milestone on the path to doing parallelization correctly.

Sorry for the long post.  But, thanks for asking the question.  If
the thread continues, it should continue on Swarm-Modelling.

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