Re: [Swarm-Modelling] SWARM on Clusters

[gepr]

Marcus G. Daniels writes:
 > Sunwoo Park wrote:
 > >I just joined in this mailing list.
 > >I have a simple question regarding SWARM software.
 > >Is there any SWARM implementation that runs on cluster machines (or MPP
 > >machines) based on Message Passing Paradigm (e.g., MPI) ?
 > >
 > Swarm has a fine-grained knowledge of concurrency during a simulation.  
 > When multiple agents do something at the same timestep, Swarm knows 
 > this.   But that's just a little atom of the whole simulation execution 
 > sequence.  What this means is that in order for Swarm to exploit this 
 > knowledge on a parallel computer, it is necessary to be able to 
 > efficiently get that atom of computation to a physical processor.  A 
 > cluster, like a Beowulf arrangement of PCs, can't do this because the 
 > communication expense of getting the atom to the processor not amortized 
 > by the computation done.   A SMP or NUMA system can do this because the 
 > communication/overhead expense of getting the computation to the 
 > processor is small.  So if you have a two or four or eight way Opteron 
 > or Sun system or a big NUMA system like a SGI Altix, the interconnect 
 > between processors could reasonably slurp up these atoms and there would 
 > be a scalability win.
 > 
 > I think it would be hard to make a message passing system scale very 
 > well based on an architecture like Swarm.   You'd need low-latency 
 > interconnect, maybe Myrinet.
 > 
 > In any case, Swarm doesn't implement either.  A multithreaded Swarm 
 > would be feasible, but would assume a shared memory system like I mentioned.

But, you're only talking about fine-grained parallelism.  Many models
only need a more coarse type of distribution.  I think it would be
fairly simple and useful to farm whole swarms out to different machines.

If I remember correctly an REU student named Davi did this with MPI
awhile back and it was pretty simple and worked well.  I also think 
that Bob Bell did this with Arborscapes.  You still out there, Bob?

Awhile back, we tried to come up with a suite of "types of
parallelism" because the user community asks for it but it's never
been clear what the best route forward is.  Implementing it so that
the current concurrency model automatically makes decisions based on
the structure of the Activities is not necessarily the best path, 
even though that would be an interesting project.

The best paths, I think, are:

  1) [somehow] parallelize the space library structures, and
  2) provide a "drone-like" or experiment swarm capability that 
     could intelligently distribute the computation.

I think this would cover 80% of the needs of the community, though
I really don't have any idea of how to go about (1)... and, if 
effort were put into the space library, it really should be _totally_
refactored, anyway.... or tossed and rewritten. [grin]

-- 
glen e. p. ropella              =><=                           Hail Eris!
H: 503.630.4505                              http://www.ropella.net/~gepr
M: 971.219.3846                               http://www.tempusdictum.com