|
BackgroundAt a conceptual level, the vocabulary for building Swarm models is straightforward: agent behaviors are Actions and these Actions are driven by Schedules. An Action is a recipient target (e.g. an agent), combined with some transformation on that target. Agents can combine Schedules to get multifaceted behavior patterns, and they have the option of modifying Schedules as a simulation runs. Multiple agents can be run together in a coordinated time and space, a Swarm. These three features (Action, Schedule, and Swarm), make it possible to describe agents in a modular and precise way. Further, the Swarm simulator processes these descriptions in such a way that emergent concurrent Actions are tracked, and thus the system is, in principle, highly scalable. A way to talk in precise terms about primitive agent actions is needed. Sometimes agent actions will be non-linear transformations of agent state, and often actions will need to be mechanistic. As of the last release of Swarm, models must represent Action targets and messages as Java or Objective C objects and methods on those objects. Although Java is popular, it still takes a fair amount of time to learn, and is oriented towards implementation, not experimentation, i.e. a single intent mapping to straightforward chunks of code. Although an implementation language like C++, Java, or Objective C can certainly satisfy this need for describing the meaning of an Action, in a very real sense these languages are overkill and unwieldy for the initial stages of the modeling enterprise. In contrast, scripting languages are designed to be dynamic, incremental, and forgiving. The next release of Swarm, will support JavaScript and Scheme in addition to Objective C and Java. This support is actually in the source tree already, and available to inquisitive users that want to build Swarm snapshots from source code. As with anything, there are tradeoffs. Interactive scripting languages are slow, in general. Being dynamic and forgiving means that more stuff has to be checked more of the time. Once a clear hypothesis is formed (e.g. in the scripting environment), there will typically be a need to scale the system up to see what dynamics occur for a larger population of agents. In this situation performance becomes a serious consideration -- even to the point that the overhead of the Java virtual machine or the overhead of dynamic method dispatch is prohibitive in parts of a model. It is beneficial if Swarm models can be described in a tightly controlled environment such as C++. With the next release of Swarm, we've targeted a system specifically intended to solve this problem: COM (http://www.microsoft.com/COM). COM is a technology that facilitates interoperable components, regardless of their implementation language. COM has the attribute of being very lightweight and fast for the common case of messages within components on the same computer. But don't get the idea we're dependent on Microsoft. We're using the Mozilla COM implementation, XPCOM, which is portable across Windows, MacOS, and Unix, and has completely freely redistributable source code. "Show me the money", you scream! Snapshots and demo code are at: |
Background