Re: [Swarm-Modelling] Question

[Miles Parker]

> explain our framework in a little detail. The main features of Flame
> are high performance and a formal testing capability. There are three

The formal testing aspect is something that I think is really  
important and impressive.

> . Performance is
> very critical for us, and hence we would recommend the use of C
> functions, as we are able to perform bit-level optimizations to the
> generated executable.

...better then machine specific binary! :)

> performance and testability. A by product of using a underlying formal
> X-machine model is that we are able to test the model, without
> actually running the code for simulating a million agents.

Right, there is  a similar goal of the metaABM approach, but in a less  
constrained but therefore less certain fashion. That is, from having a  
higher-level specification, one can do some sanity checking and infer  
opportunities for simplifying or validating all sorts of runtime logic.
> The core parser/compiler will parse the XMML definition and the
> related user-defined functions to generate optimized code for your
> platform. We currently support a large number of HPC platforms and
> user desktops(*nix, mac,pc). The only extra C dependencies for the
> generated code will be MPICH for the parallel version else none apart
> from the standard C libraries.

Does this optimization happen now? Can you give a simple example, say  
some kind vector operation? Do your targets make use of processor  
specific instruction sets, e.g. SSE4, AltiVec?
>

> So to allow Metascape to generate Flame code, all that needs to be
> done is to transform your meta-model to a Flame XMML document and
> user-defined functions wrapped in C.

Right, so early supposition is correct then. Of course it may be that  
the target semantics are somewhat more limited then say the full set  
of metaABM definitions, esp. initially. I'm about to introduce a  
feature that allows one to specify checks so that the user at least  
can have a nice notification that for example "the capability 'x' you  
are using is not supported by the FLAME target."

> The reverse use-case might be
> tricky to achieve, although we do have two concurrent projects that is
> looking into specifying high-level code as part of the XMML itself and
> libraries.

Right, as metaABM's strength is on the high-level side and end-user  
oriented tools so I think the other way makes a lot more sense.

> This won't allow us to completely remove all the
> user-defined functions, but rather it will be embedded within the XMML
> itself as tags. There are certain issues regarding this, an example is
> what are the fundamental concepts we should aim to support, list,
> tuples, while loops, etc to acheive maximum usability.

Just as a side note, metaABM explicitly does not support explicit loop  
structures and some other constructs precisely to prevent users from  
over specifying behavior that does not need to be specified in that  
way. This does rule out say specialized numerical functions, but that  
is a 'feature' as those should be specified as abstract callable  
functions and implemented as targets.

> Hope this helps clear up things about Flame and hope this will kindle
> your "flames" of curiosity in our project. Sorry for the length of
> this email, I didn't have the time to write a shorter one.

My emails tend to be even more reducible. ;)