Re: [Swarm-Modelling] Question

[Marcus G. Daniels]

Susheel Varma wrote:
> There are three main components to Flame:
>
> a. Agent specification via XMML(X-machine Markup Language)
> b. User defined functions or behaviours associated with each agent.
> c. The core compiler/parser that will generate a serial and/or
> parallel version of the code.
>   
Would it be correct to say this amounts to Web Service Definition 
Language (WSDL) for MPI?    If so, that seems like a very useful 
thing.   I have not recently reviewed the many number of the available 
distributed object systems, but as far as I know none of them really 
address the problem of the high performance computing programmer:  Are 
communication costs amortized?    Yes, I'm sure many of them are highly 
optimized, but at the end the day what's needed is a yes/no answer, and 
then some guidance on what to do if it is not.

The many factors that determine whether a pattern of communication takes 
less time than the calculation it facilitates are not so easy to measure 
as they depend on a complex interaction of hardware, operating system, 
and network switching.   For (single chip) multi-core codes, the 
architecture will be well-described for the compiler.   Not so for 
ad-hoc clusters.   It seems to me the best hope is runtime-profiling, 
along the lines of profile-guided optimization.     An OpenMP or 
auto-vectorizing compiler typically can be instructed to say "Loop could 
not be parallelized because there was not enough work".   It would be 
neat to have an ABM compiler say the same thing, but as an infererence 
informed by runtime execution costs (e.g. measuring latency distribution 
of various messages' as a function of their payload size).    Ideally, 
it would be the compiler and could really `see' all of program.

Swarm has something a lot like XMML, it's just not that obvious.   Swarm 
describes its interfaces using Objective C protocol files (but on 
steroids using markup), and from that an abstract notion of messages and 
variables/singletons is described.   It would be a pretty simple matter 
to write out the Swarm interfaces as XMML (actually Swarm already does 
write XML, it's just that it is DocBook XML, not XML intended for 
stubbing), or for that matter generate MPI stubs directly.  Internally, 
the scheduler, etc. has no interest in what kind of object it is 
messaging, it could easily hand that off to XMML I think.  

That's just an aside, though.  I think the future is declarative model 
description and math-like notation for agent models that lends itself to 
(partial) analysis.   Building a system that can do that on existing 
toolkits may end up just being a temporary unpretty hack..

Marcus