We have provided a brief overview of ABM. We examined briefly the different possible approaches to general simulation so as to show the possible alternatives to ABM and place it in context. The approach that a modeller uses will depend on the context.
From our overview of ABM it should now be clear that ABM as an approach to simulation should be given serious consideration if any of the following statements are true.
1. The primarily interest is in emergent properties;
2. There are no solvable (computable) equations that describe the overall sys- tem properties;
3. Any equations we have rely on simplifying assumptions that we cannot or do not wish to stand over;
5. The individual behaviours are high level behaviours and the agents are proac- tive.
An ABSS will have the following properties (section 2.2): 1. Heterogeneity;
2. Autonomy; 3. Local Interactions; 4. Explicit Space; 5. Bounded Rationality.
If a model does not have these properties then it is not suitable for ABSS. During each step of a simulation all agent interaction takes place as if simulta- neously in time. We note that there are two different approaches to implementing this condition, known as the synchronous and asynchronous approaches. The asyn- chronous approach proceeds by executing each interaction in a sequential order. to remove any simulation artefacts that may occur due to the ordering used we ran- domise the order for each step. This is currently the preferred approach in ABSS.
Asynchronous has become the prevalent updating method used in ABSS. The ability to execute a sequence of agent actions in a random order, an essential part of asynchronous simulations and forms part of StupidModel [Railsback et al., 2005], a suite of models designed to test the suitability of any toolkit for ABM devel- opment. Many assume that asynchronous is more realistic for real world based simulations [Caron-Lormier et al., 2008], [Cornforth et al., 2005],
[Newth and Cornforth, 2009]. However [Fat`es, 2013] states that the asynchronous approach only makes sense if the interactions are instantaneous, something that is seldom true in the real world. These contradictory conclusions drawn from differ- ent published sources indicate that more research into the effects of AU and SU are needed.
The alternative approach is favoured more in CA based simulations. Here si- multaneous interactions within a step are achieved by allowing agents to only see the state of the world (neighbouring agents and locations) as it appeared at the start of the step. All interaction outcomes are calculated based on these values. Any updates that occur during a step (as a result of agent interactions) are hidden and only applied at the end of the step (as if simultaneously).
The differences between these two approaches and how they affect the over- all ABM properties are at the heart of this thesis. There has been some work on the differences between synchronous and asynchronous ABM updating but much less work on how to extend synchronous updating to complex ABM interactions. It has been shown that even in simple CA-based simulations the synchronous and asynchronous interpretation of identical models can lead to completely dif- ferent results [Huberman and Glance, 1993, Sch¨onfisch and de Roos, 1999], espe- cially in higher density simulations [Caron-Lormier et al., 2008] and asynchronous is generally less restrained [Cornforth et al., 2005] in behaviour outcomes. While [Ruxton and Saravia, 1998] says that the approach taken should be chosen with care and specific regard the process being simulated, in [Caron-Lormier et al., 2008] it is stated that most modellers choose an approach based on personal experience rather than based on evidence of its correctness.
Conway’s Game of Life has been implemented as an asynchronous CA
[Lee et al., 2004] but it has further been proven [Nehaniv, 2003] that any synchronous CA can be implemented as an asynchronous CA. This is achieved through local synchronisation instead of global synchronisation. Each cell in the CA keeps track of its previous state and its current state and when chosen to update will only up- date itself if its neighbours are all operating on the same timestamp. So while this allows asynchrony every cell is always either one time step behind, one time step ahead or at the same time step as its neighbours. That is, it is still synchronised but only locally. This, it could be argued, is an example of synchronous updating without a Global clock.
The work that has been done concentrates only on the simplest of ABM inter- action: basic movement across locations. More complex interaction types, such as those in Sugarscape have been ignored. Modellers seem to have uncritically accepted the arguments presented for asynchronous updates.
We will examine the assumptions behind AU in Chapter Six and propose new synchronous algorithms that do not suffer from the flaws inherent in the asyn- chronous approaches.
In the next chapter we survey the issues introduced by concurrency. We will show how to measure the performance of an algorithm (concurrent and sequential) and show how concurrency is currently employed in ABM.
Chapter 3
Concurrency
3.1
Introduction
Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel [Ben, 2006]. If we call a sequential program a process then we can define a con- current programas a set of processes that are executed in abstract parallelism. In a minority of cases a concurrent program is composed of completely independent processes and these can all be run in parallel without any problems. Such problems are termed embarrassingly parallel. However, in the vast majority of cases concur- rent programs cannot be broken into completely independent processes. There will exist interdependencies between these processes that constrain the relative speeds of their execution.
This extra complexity, brought about by the introduction of concurrency [Sutter and Larus, 2005, Lee, 2000], means that it is difficult to produce correct solutions even for small problems. The processes that make up a concurrent pro- gram need to communicate with each other in order to share data. There are two approaches to communication between processes: shared memory and message passing[Klaiber and Levy, 1994].
All concurrent programs must deal with the issues of contention and commu- nication. Concurrency is only introduced to reduce overall time required by a com- putation to complete (that is, speed-up a piece of code). The speed-up that comes from changing a serial computation into a functionally equivalent concurrent com- putation will depend on how much concurrency can be introduced and the depen- dencies that exist between the concurrent tasks. Generally we want to achieve as
much speed up as possible and this requires us to maximize opportunities for par- allelization. Optimal speed up is linear but the achievable speed-up will vary from computation to computation. Here we ignore the possibility of superlinear1speed increases that can be caused by, for example, the concurrent algorithm being more efficient than the original sequential algorithm it is replacing. We address these issues in more detail in the following sections.