Chapter 9
FLAME’s Future
9.1
FLAME to FLAME GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
9.1.1
Visualizing Is Easy in FLAME GPU . . . . . . . . . . . . . . . . . . . . 273
9.1.2
Utilizing Vector Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.2
Commercial Applications of FLAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.1 FLAME to FLAME GPU
The FLAME GPU version shares similar principles as FLAME, such as
using an XML specification language as initial description of the models [162].
However, agent functions are written in C++, and interface with CUDA libraries so that they are processed on the local graphics card. The models
showed an 80% improvement in simulation time and allowed real-time and
3D rendering of results while the simulations are running [108]. Each agent
runs as an independent thread, performing its functions wrapped by the GPU
kernel.
Although both versions of FLAME use similar methodologies and description languages, a number of changes were introduced in writing the models for
every architecture. Most of the changes are due to basic capabilities of High
Performance Computing (HPC) grid versus GPU cards. These changes are
discussed, highlighting some issues raised by portability from modelers view:
Writing Agents. From the modeler perspective, implementing the system
in FLAME in general was quite straight forward provided certain rules
were being followed. Due to the synchronization nature of the framework,
predefined before the simulation runs, FLAME does not allow agent
behavior to contain loops, which may cause it to go back to a previous
state. Similarly communications are decided at specific steps before the
code is parallelized to ensure synchronization points (when the message
boards are locked for reading and writing), to prevent any discordances
in message data read, following a step-by-step progression in the model.
Pre-Allocation of Agent Memory. The grid FLAME version allowed
memory to be allocated dynamically. This allowed complex agent memory such as using dynamic arrays or linked lists to be generated, as
the model runs on the grid. This, however, is not the same on GPUs.
247
FLAME’s Future
9.1
FLAME to FLAME GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
9.1.1
Visualizing Is Easy in FLAME GPU . . . . . . . . . . . . . . . . . . . . 273
9.1.2
Utilizing Vector Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.2
Commercial Applications of FLAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.1 FLAME to FLAME GPU
The FLAME GPU version shares similar principles as FLAME, such as
using an XML specification language as initial description of the models [162].
However, agent functions are written in C++, and interface with CUDA libraries so that they are processed on the local graphics card. The models
showed an 80% improvement in simulation time and allowed real-time and
3D rendering of results while the simulations are running [108]. Each agent
runs as an independent thread, performing its functions wrapped by the GPU
kernel.
Although both versions of FLAME use similar methodologies and description languages, a number of changes were introduced in writing the models for
every architecture. Most of the changes are due to basic capabilities of High
Performance Computing (HPC) grid versus GPU cards. These changes are
discussed, highlighting some issues raised by portability from modelers view:
Writing Agents. From the modeler perspective, implementing the system
in FLAME in general was quite straight forward provided certain rules
were being followed. Due to the synchronization nature of the framework,
predefined before the simulation runs, FLAME does not allow agent
behavior to contain loops, which may cause it to go back to a previous
state. Similarly communications are decided at specific steps before the
code is parallelized to ensure synchronization points (when the message
boards are locked for reading and writing), to prevent any discordances
in message data read, following a step-by-step progression in the model.
Pre-Allocation of Agent Memory. The grid FLAME version allowed
memory to be allocated dynamically. This allowed complex agent memory such as using dynamic arrays or linked lists to be generated, as
the model runs on the grid. This, however, is not the same on GPUs.
247