new

diff --git a/BookGPU/Chapters/chapter17/biblio.bib b/BookGPU/Chapters/chapter17/biblio.bib
index c951cb01aa2036352c0001dd216abb7f424f2b85..575f9cf295f5501acd456dcac5734c1091ccfa55 100644 (file)
--- a/BookGPU/Chapters/chapter17/biblio.bib
+++ b/BookGPU/Chapters/chapter17/biblio.bib
@@ -17,7 +17,7 @@
 }
 
 @INPROCEEDINGS{Aaby:2010:ESA:1808143.1808181,
 }
 
 @INPROCEEDINGS{Aaby:2010:ESA:1808143.1808181,

-  author = {Aaby, Brandon G. and Perumalla, Kalyan S. and Seal, Sudip K.},
+  author = {Aaby, B. G. and Perumalla, K. S. and Seal, S. K.},

   title = {Efficient simulation of agent-based models on multi-GPU and multi-core
        clusters},
   booktitle = {Proceedings of the 3rd International ICST Conference on Simulation
   title = {Efficient simulation of agent-based models on multi-GPU and multi-core
        clusters},
   booktitle = {Proceedings of the 3rd International ICST Conference on Simulation


@@ -99,7 +99,7 @@
 
 
 @MISC{Bleiweiss_2009,
 
 
 @MISC{Bleiweiss_2009,

- author = {Bleiweiss, Avi},
+ author = {Bleiweiss, A.},

  title = {Multi Agent Navigation on the GPU},
  howpublished = "\url{developer.download.nvidia.com/presentations/2009/GDC/MultiAgentGPU.pdf}",
  year = {2009},
  title = {Multi Agent Navigation on the GPU},
  howpublished = "\url{developer.download.nvidia.com/presentations/2009/GDC/MultiAgentGPU.pdf}",
  year = {2009},


@@ -179,7 +179,7 @@
 }
 
 @INPROCEEDINGS{Fischer:2009:GAP:1803298.1803361,
 }
 
 @INPROCEEDINGS{Fischer:2009:GAP:1803298.1803361,

-  author = {Fischer, Leonardo G. and Silveira, Renato and Nedel, Luciana},
+  author = {Fischer, L. G. and Silveira, R. and Nedel, L.},

   title = {GPU Accelerated Path-Planning for Multi-agents in Virtual Environments},
   booktitle = {Proceedings of the 2009 VIII Brazilian Symposium on Games and Digital
        Entertainment},
   title = {GPU Accelerated Path-Planning for Multi-agents in Virtual Environments},
   booktitle = {Proceedings of the 2009 VIII Brazilian Symposium on Games and Digital
        Entertainment},


@@ -216,7 +216,7 @@
 }
 
 @incollection {Maitre2009,
 }
 
 @incollection {Maitre2009,

-   author = {Maitre, Ogier and Lachiche, Nicolas and Clauss, Philippe and Baumes, Laurent and Corma, Avelino and Collet, Pierre},
+   author = {Maitre, O. and Lachiche, N. and Clauss, P. and Baumes, L. and Corma, A. and Collet, P.},

    affiliation = {LSIIT University of Strasbourg, France},
    title = {Efficient Parallel Implementation of Evolutionary Algorithms on GPGPU Cards},
    booktitle = {Euro-Par 2009 Parallel Processing},
    affiliation = {LSIIT University of Strasbourg, France},
    title = {Efficient Parallel Implementation of Evolutionary Algorithms on GPGPU Cards},
    booktitle = {Euro-Par 2009 Parallel Processing},


@@ -295,8 +295,8 @@
 }
 
 @INPROCEEDINGS{Mistry:2011:APF:1964179.1964193,
 }
 
 @INPROCEEDINGS{Mistry:2011:APF:1964179.1964193,

-  author = {Mistry, Perhaad and Gregg, Chris and Rubin, Norman and Kaeli, David
-       and Hazelwood, Kim},
+  author = {Mistry, P. and Gregg, C. and Rubin, N. and Kaeli, D.
+       and Hazelwood, K.},

   title = {Analyzing program flow within a many-kernel OpenCL application},
   booktitle = {Proceedings of the Fourth Workshop on General Purpose Processing
        on Graphics Processing Units},
   title = {Analyzing program flow within a many-kernel OpenCL application},
   booktitle = {Proceedings of the Fourth Workshop on General Purpose Processing
        on Graphics Processing Units},


@@ -450,8 +450,8 @@ pages = {517-527}
 
 
 @inproceedings{Vowel02,
 
 
 @inproceedings{Vowel02,

-  author    = {Da Silva Joao Luis T.  and
-                Demazeau, Yves},
+  author    = {Da Silva Joao Luis, T.  and
+                Demazeau, Y.},

   title     = {Vowels co-ordination model},
   booktitle = {AAMAS},
   year      = {2002},
   title     = {Vowels co-ordination model},
   booktitle = {AAMAS},
   year      = {2002},


@@ -508,7 +508,7 @@ pages = {303-311}
 }
 
 @InProceedings{repast_home,
 }
 
 @InProceedings{repast_home,

-author = {North, M.J. and Howe, T.R. and  Collier, N.T. and  Vos, J.R},
+author = {North, M. J. and Howe, T. R. and  Collier, N. T. and  Vos, J. R.},

 title = {A Declarative Model Assembly Infrastructure for Verification and Validation},
 booktitle = {Advancing Social Simulation: The First World Congress},
 year = {2007},
 title = {A Declarative Model Assembly Infrastructure for Verification and Validation},
 booktitle = {Advancing Social Simulation: The First World Congress},
 year = {2007},


@@ -518,7 +518,7 @@ address = {Heidelberg, FRG}
 
 
 @INPROCEEDINGS{Guy09clearpath,
 
 
 @INPROCEEDINGS{Guy09clearpath,

-    author = {Stephen J. Guy and Jatin Chhugani and Changkyu Kim and Nadathur Satish and Ming C. Lin and Dinesh Manocha and Pradeep Dubey},
+    author = {S. J. Guy and J. Chhugani and C. Kim and N. Satish and M. C. Lin and D. Manocha and P. Dubey},

     title = {ClearPath: Highly Parallel Collision Avoidance for Multi-Agent Simulation},
     booktitle = {ACM SIGGRAPH/EUROGRAPHICS SYMPOSIUM ON COMPUTER ANIMATION},
     year = {2009},
     title = {ClearPath: Highly Parallel Collision Avoidance for Multi-Agent Simulation},
     booktitle = {ACM SIGGRAPH/EUROGRAPHICS SYMPOSIUM ON COMPUTER ANIMATION},
     year = {2009},


@@ -527,7 +527,7 @@ address = {Heidelberg, FRG}
 }
 
 @inproceedings{Kiran2010,
 }
 
 @inproceedings{Kiran2010,

- author = {Kiran, Mariam and Richmond, Paul and Holcombe, Mike and Chin, Lee Shawn and Worth, David and Greenough, Chris},
+ author = {Kiran, M. and Richmond, P. and Holcombe, M. and Chin, L. S. and Worth, D. and Greenough, C.},

  title = {FLAME: simulating large populations of agents on parallel hardware architectures},
  booktitle = {Proceedings of the 9th International Conference on Autonomous Agents and Multiagent Systems: volume 1 - Volume 1},
  series = {AAMAS '10},
  title = {FLAME: simulating large populations of agents on parallel hardware architectures},
  booktitle = {Proceedings of the 9th International Conference on Autonomous Agents and Multiagent Systems: volume 1 - Volume 1},
  series = {AAMAS '10},


@@ -544,7 +544,7 @@ address = {Heidelberg, FRG}
 }
 
 @inproceedings{Dsouza2007,
 }
 
 @inproceedings{Dsouza2007,

-author={D'SOUZA R M, Lysenko M, Rahmani K},
+author={D'Souza R. M., Lysenko M, R. K.},

 title={Sugarscape on Steroids: Simulating Over a Million Agents at Interactive Rates},
 year={2007},
 booktitle={Proceedings of the Agent 2007 Conference},
 title={Sugarscape on Steroids: Simulating Over a Million Agents at Interactive Rates},
 year={2007},
 booktitle={Proceedings of the Agent 2007 Conference},


@@ -697,7 +697,7 @@ inhal = {no},
 domainehal = {INFO:INFO_NI, INFO:INFO_DC, INFO:INFO_IU},
 equipe = {cartoon},
 classement = {ACTI},
 domainehal = {INFO:INFO_NI, INFO:INFO_DC, INFO:INFO_IU},
 equipe = {cartoon},
 classement = {ACTI},

-author = {Laville, Guillaume and Mazouzi, Kamel and Lang, Christophe and Marilleau, Nicolas and Philippe, Laurent},
+author = {Laville, G. and Mazouzi, K. and Lang, C. and Marilleau, N. and Philippe, L.},

 title = {Using {GPU} for Multi-agent Multi-scale Simulations},
 booktitle = {DCAI'12, 9-th Int. Conf. on Advances in Intelligent and Soft Computing},
 pages = {197--204},
 title = {Using {GPU} for Multi-agent Multi-scale Simulations},
 booktitle = {DCAI'12, 9-th Int. Conf. on Advances in Intelligent and Soft Computing},
 pages = {197--204},


@@ -717,7 +717,7 @@ domainehal = {INFO:INFO_NI, INFO:INFO_DC, INFO:INFO_IU},
 equipe = {cartoon},
 classement = {ACTI},
 corerank = {C},
 equipe = {cartoon},
 classement = {ACTI},
 corerank = {C},

-author = {Laville, Guillaume and Mazouzi, Kamel and Lang, Christophe and Marilleau, Nicolas and Philippe, Laurent},
+author = {Laville, G. and Mazouzi, K. and Lang, C. and Marilleau, N. and Philippe, L.},

 title = {Using {GPU} for Multi-agent Soil Simulation},
 booktitle = {PDP 2013, 21st Euromicro International Conference on Parallel, Distributed and Network-based Computing},
 pages = {***--***},
 title = {Using {GPU} for Multi-agent Soil Simulation},
 booktitle = {PDP 2013, 21st Euromicro International Conference on Parallel, Distributed and Network-based Computing},
 pages = {***--***},

diff --git a/BookGPU/Chapters/chapter17/ch17.aux b/BookGPU/Chapters/chapter17/ch17.aux
index 032ebff11e43eb73dfcf1a4948822299d249bc67..3fb7c46b41de3f6a77866589476d5ee197cae77e 100644 (file)
--- a/BookGPU/Chapters/chapter17/ch17.aux
+++ b/BookGPU/Chapters/chapter17/ch17.aux
@@ -1,5 +1,5 @@
 \relax 
 \relax 

-\@writefile{toc}{\author{G. Laville, C. Lang, K. Mazouzi, N. Marilleau, B. Herrmann, L. Philippe}{}}
+\@writefile{toc}{\author{Guillaume Laville, Christophe Lang, Kamel Mazouzi, Nicolas Marilleau, B\IeC {\'e}n\IeC {\'e}dicte Herrmann, Laurent Philippe}{}}

 \@writefile{loa}{\addvspace {10\p@ }}
 \@writefile{toc}{\contentsline {chapter}{\numberline {16}Implementing MAS on GPU}{363}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{loa}{\addvspace {10\p@ }}
 \@writefile{toc}{\contentsline {chapter}{\numberline {16}Implementing MAS on GPU}{363}}
 \@writefile{lof}{\addvspace {10\p@ }}


@@ -24,7 +24,7 @@
 \newlabel{ch17:listing:collembola-reduc}{{16.2}{370}}
 \@writefile{lol}{\contentsline {lstlisting}{\numberline {16.2}Collembola OpenCL reduction kernel}{370}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {16.3.3}Collembola performance}{371}}
 \newlabel{ch17:listing:collembola-reduc}{{16.2}{370}}
 \@writefile{lol}{\contentsline {lstlisting}{\numberline {16.2}Collembola OpenCL reduction kernel}{370}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {16.3.3}Collembola performance}{371}}

-\@writefile{lof}{\contentsline {figure}{\numberline {16.2}{\ignorespaces Performances CPU et GPU du mod\IeC {\`e}le Collemboles\relax }}{371}}
+\@writefile{lof}{\contentsline {figure}{\numberline {16.2}{\ignorespaces Performance of the Collembola model on CPU and GPU\relax }}{371}}

 \newlabel{ch17:fig:mior_perfs_collem}{{16.2}{371}}
 \@writefile{toc}{\contentsline {section}{\numberline {16.4}Second example}{372}}
 \newlabel{ch17:sec:2ndmodel}{{16.4}{372}}
 \newlabel{ch17:fig:mior_perfs_collem}{{16.2}{371}}
 \@writefile{toc}{\contentsline {section}{\numberline {16.4}Second example}{372}}
 \newlabel{ch17:sec:2ndmodel}{{16.4}{372}}


@@ -55,7 +55,7 @@
 \newlabel{ch17:fig:mior_perfs_tesla}{{16.5}{380}}
 \@writefile{lof}{\contentsline {figure}{\numberline {16.6}{\ignorespaces CPU and GPU performance on a personal computer with a Geforce 8800GT\relax }}{381}}
 \newlabel{ch17:fig:mior_perfs_8800gt}{{16.6}{381}}
 \newlabel{ch17:fig:mior_perfs_tesla}{{16.5}{380}}
 \@writefile{lof}{\contentsline {figure}{\numberline {16.6}{\ignorespaces CPU and GPU performance on a personal computer with a Geforce 8800GT\relax }}{381}}
 \newlabel{ch17:fig:mior_perfs_8800gt}{{16.6}{381}}

-\@writefile{toc}{\contentsline {section}{\numberline {16.5}Analysis and recommandations}{381}}
+\@writefile{toc}{\contentsline {section}{\numberline {16.5}Analysis and recommendations}{381}}

 \newlabel{ch17:analysis}{{16.5}{381}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {16.5.1}Analysis}{381}}
 \@writefile{lof}{\contentsline {figure}{\numberline {16.7}{\ignorespaces Execution time of one multi-simulation kernel on the Tesla platform\relax }}{382}}
 \newlabel{ch17:analysis}{{16.5}{381}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {16.5.1}Analysis}{381}}
 \@writefile{lof}{\contentsline {figure}{\numberline {16.7}{\ignorespaces Execution time of one multi-simulation kernel on the Tesla platform\relax }}{382}}

diff --git a/BookGPU/Chapters/chapter17/ch17.tex b/BookGPU/Chapters/chapter17/ch17.tex
index 9d458de3b2fd3962e6b61691c5984f94dcd573d6..d410caf13d2d6b23551a7202203cd073b63de7ff 100755 (executable)
--- a/BookGPU/Chapters/chapter17/ch17.tex
+++ b/BookGPU/Chapters/chapter17/ch17.tex
@@ -1,4 +1,4 @@
-\chapterauthor{G. Laville, C. Lang, K. Mazouzi, N. Marilleau, B. Herrmann, L. Philippe}{Femto-ST Institute, University of Franche-Comt{\'e}}
+\chapterauthor{Guillaume Laville, Christophe Lang, Kamel Mazouzi, Nicolas Marilleau, Bénédicte Herrmann, Laurent Philippe}{Femto-ST Institute, University of Franche-Comt{\'e}}

 
 \newlength\mylen
 \newcommand\myinput[1]{%
 
 \newlength\mylen
 \newcommand\myinput[1]{%


@@ -22,7 +22,7 @@ systems are often modeled by mathematical representations and their
 dynamic behavior simulated by differential equations. The simulation
 of the system thus often relay on the resolution of a linear system
 that can be efficiently computed on a graphical processing unit as
 dynamic behavior simulated by differential equations. The simulation
 of the system thus often relay on the resolution of a linear system
 that can be efficiently computed on a graphical processing unit as

-shown in the preceeding chapters. But when the behavior of the system
+shown in the preceding chapters. But when the behavior of the system

 elements is not uniformly driven by the same law, when these elements
 have their own behavior, the modeling process is too complex to rely
 on formal expressions. In this context MAS is a recognized approach to
 elements is not uniformly driven by the same law, when these elements
 have their own behavior, the modeling process is too complex to rely
 on formal expressions. In this context MAS is a recognized approach to


@@ -62,7 +62,7 @@ parallelism.
 Another key point that advocates for the use of many-core in MAS is
 the growing need for multi-scale simulations. Multi-scale simulations
 explore problems with interactions between several scales. The
 Another key point that advocates for the use of many-core in MAS is
 the growing need for multi-scale simulations. Multi-scale simulations
 explore problems with interactions between several scales. The

-different scales use different granularities of the structure and
+different scales use different granularity of the structure and

 potentially different models. Most of the time the lower scale
 simulations provide results to higher scale simulations. In that case
 the execution of the simulations can easily be distributed between the
 potentially different models. Most of the time the lower scale
 simulations provide results to higher scale simulations. In that case
 the execution of the simulations can easily be distributed between the


@@ -70,8 +70,8 @@ local cores and a many-core architecture, i.e. a GPU device.
 
 We explore in this chapter the use of many-core architectures to
 execute agent-based simulations. We illustrate our reflexion with two
 
 We explore in this chapter the use of many-core architectures to
 execute agent-based simulations. We illustrate our reflexion with two

-uses cases: the colembola simulator designed to simulate the diffusion
-of collembola between plots of land and the MIOR simulator that
+uses cases: the Colembola simulator designed to simulate the diffusion
+of Colembola between plots of land and the MIOR simulator that

 reproduces effects of earthworms on bacteria dynamics in a bulked
 soil. In Section \ref{ch17:ABM} we present the work related to MAS and
 parallelization with a special focus on many-core use. In sections
 reproduces effects of earthworms on bacteria dynamics in a bulked
 soil. In Section \ref{ch17:ABM} we present the work related to MAS and
 parallelization with a special focus on many-core use. In sections


@@ -121,7 +121,7 @@ primitives or indirectly through the information stored in the
 environment.
 
 Agent based simulations have been used for more than one decade to
 environment.
 
 Agent based simulations have been used for more than one decade to

-reproduce, understand even predic complex system dynamic. They have proved their interest in various
+reproduce, understand even predict complex system dynamic. They have proved their interest in various

 scientific communities. Nowadays generic agent based frameworks are
 promoted such as Repast~\cite{repast_home} or
 NetLogo~\cite{netlogo_home} to implement simulators. Many ABM such as
 scientific communities. Nowadays generic agent based frameworks are
 promoted such as Repast~\cite{repast_home} or
 NetLogo~\cite{netlogo_home} to implement simulators. Many ABM such as


@@ -280,7 +280,7 @@ of agents or simulations sharing common data (such as the environment)
 or algorithms (such as the background evolution process).
 
 In the following examples the JOCL~\cite{jocl_home} binding is used
 or algorithms (such as the background evolution process).
 
 In the following examples the JOCL~\cite{jocl_home} binding is used

-to access the OpenCL platfmorm from the Java programming language.
+to access the OpenCL platform from the Java programming language.

 
 In the next sections we present two practical cases that will be
 studied in details, from the model to its implementation and 
 
 In the next sections we present two practical cases that will be
 studied in details, from the model to its implementation and 


@@ -290,7 +290,7 @@ performance.
 \label{ch17:sec:1stmodel}
 
 The first model, the Collembola model, simulates the propagation of
 \label{ch17:sec:1stmodel}
 
 The first model, the Collembola model, simulates the propagation of

-collembolas in flieds and forests. It is based on a diffusion
+collembolas in fields and forests. It is based on a diffusion

 algorithm which illustrates the case of agents with a simple behavior
 and few synchronization problems.
 
 algorithm which illustrates the case of agents with a simple behavior
 and few synchronization problems.
 


@@ -299,11 +299,11 @@ and few synchronization problems.
 
 The Collembola model is an example of multi-agent system using GIS (Geographical Information System)
  and survey data (population count)
 
 The Collembola model is an example of multi-agent system using GIS (Geographical Information System)
  and survey data (population count)

- to modelize the evolution of the biodiversity
-across land plots. A first version of this model has been developed with Netlogo framework by Bioemco and UMMISCO researchers. In this model, the biodiversity is modelized by populations of
+ to model the evolution of the biodiversity
+across land plots. A first version of this model has been developed with Netlogo framework by Bioemco and UMMISCO researchers. In this model, the biodiversity is modeled by populations of

 athropod individuals, the Collembola, which can reproduce and diffuse
 to favorable new habitats. The simulator allows to study the diffusion
 athropod individuals, the Collembola, which can reproduce and diffuse
 to favorable new habitats. The simulator allows to study the diffusion

-of collembola, between plots of land depending on their landuse
+of collembola, between plots of land depending on their use

 (artifical soil, crop, forest\ldots). In this
 model the environment is composed of the studied land and the
 colembola are agents. Every land plot is divided into several cells,
 (artifical soil, crop, forest\ldots). In this
 model the environment is composed of the studied land and the
 colembola are agents. Every land plot is divided into several cells,


@@ -340,10 +340,10 @@ associated to one plot to obtain its population.
 
 The {\bf diffusion} stage simulates the natural behavior of the
 collembola that tends toward occupying the whole space over time. This
 
 The {\bf diffusion} stage simulates the natural behavior of the
 collembola that tends toward occupying the whole space over time. This

-stage constists in computing a new value for each cell depending on
+stage consists in computing a new value for each cell depending on

 the population of the neighbor cells. This process can be assimilated
 the population of the neighbor cells. This process can be assimilated

-to a linear diffusion at each iteration of the populationof the cells
-across their neightbors.
+to a linear diffusion at each iteration of the population of the cells
+across their neighbors.

 
 These two processes are quite common in numerical computations so
 that the collembola model can be adapted to a GPU execution without
 
 These two processes are quite common in numerical computations so
 that the collembola model can be adapted to a GPU execution without


@@ -382,7 +382,7 @@ calculated, and divided by the number of neightbors. Note that, at the
 model frontier, populations can also overflow outside the environment
 grid but we do not manage those external populations, since there are
 no reason to assume our model to be isolated of its surroundings. The
 model frontier, populations can also overflow outside the environment
 grid but we do not manage those external populations, since there are
 no reason to assume our model to be isolated of its surroundings. The

-overflow by neigbors value is stored for each cell, before
+overflow by neighbors value is stored for each cell, before

 encountering the barrier. After the barrier is met, each cell read the
 overflows stored by all its neighbors at the previous step and applies
 them to its own population. In this manner, only one barrier is
 encountering the barrier. After the barrier is met, each cell read the
 overflows stored by all its neighbors at the previous step and applies
 them to its own population. In this manner, only one barrier is


@@ -403,7 +403,7 @@ could be implemented.
 In this part we present the performance of the Collembola model on
 various CPU and GPU execution
 platforms. Figure~\ref{ch17:fig:mior_perfs_collem} shows that the
 In this part we present the performance of the Collembola model on
 various CPU and GPU execution
 platforms. Figure~\ref{ch17:fig:mior_perfs_collem} shows that the

-number of cores and the processor archiecture as a strong influence on the obtained results
+number of cores and the processor architecture as a strong influence on the obtained results

 
 % : the
 % dual-core processor equipping our Thinkpad platform has two to six
 
 % : the
 % dual-core processor equipping our Thinkpad platform has two to six


@@ -425,7 +425,7 @@ number of cores and the processor archiecture as a strong influence on the obtai
 \item Older GPU cards can be slower than modern processors. This can
   be explained by the new cache and memory access optimizations
   implemented in newer generations of GPU devices. These optimizations
 \item Older GPU cards can be slower than modern processors. This can
   be explained by the new cache and memory access optimizations
   implemented in newer generations of GPU devices. These optimizations

-  reduce the penalities associated with irregular and frequent global
+  reduce the penalties associated with irregular and frequent global

   memory accesses. They are not available on our Tesla nodes.
 \item GPU curves exhibit a odd-even pattern in their performance
   results. Since this phenomenon is visible on two distinct
   memory accesses. They are not available on our Tesla nodes.
 \item GPU curves exhibit a odd-even pattern in their performance
   results. Since this phenomenon is visible on two distinct


@@ -441,7 +441,7 @@ number of cores and the processor archiecture as a strong influence on the obtai
 %begin{minipage}[t]{0.49\linewidth}
 \centering
 \includegraphics[width=0.7\linewidth]{./Chapters/chapter17/figs/collem_perfs_nothinkpad.pdf}
 %begin{minipage}[t]{0.49\linewidth}
 \centering
 \includegraphics[width=0.7\linewidth]{./Chapters/chapter17/figs/collem_perfs_nothinkpad.pdf}

-\caption{Performances CPU et GPU du modèle Collemboles}
+\caption{Performance of the Collembola model on CPU and GPU}

 \label{ch17:fig:mior_perfs_collem}
 %end{minipage}
 \end{figure}
 \label{ch17:fig:mior_perfs_collem}
 %end{minipage}
 \end{figure}


@@ -452,7 +452,7 @@ on modern hardware. These gains are more mixed on older GPU platforms
 due to the limitations when dealing with irregular memory or execution
 patterns often encountered in MAS systems. This can be closely linked
 to the availability of caching facilities on the GPU hardware and its
 due to the limitations when dealing with irregular memory or execution
 patterns often encountered in MAS systems. This can be closely linked
 to the availability of caching facilities on the GPU hardware and its

-dramatical effects depending on the locality and frequency of data
+dramatically effects depending on the locality and frequency of data

 accesses. In this case, even if the Tesla architectures provides more
 execution cores and is the far costlier solution, more recent, cheaper,
 solutions such as high-end GPU provide better performance when the
 accesses. In this case, even if the Tesla architectures provides more
 execution cores and is the far costlier solution, more recent, cheaper,
 solutions such as high-end GPU provide better performance when the


@@ -619,7 +619,7 @@ list and the number of non productive accesses.
 \end{figure}
 
 Since dynamic memory allocation is not possible yet in OpenCL and only
 \end{figure}
 
 Since dynamic memory allocation is not possible yet in OpenCL and only

-provided in the lastest revisions of the CUDA standard, these matrices
+provided in the latest revisions of the CUDA standard, these matrices

 are statically allocated. The allocation is based on the worst-case
 scenario where all OM and MM are linked as the real occupation of the
 matrix cells cannot be deduced without some kind of preprocessing
 are statically allocated. The allocation is based on the worst-case
 scenario where all OM and MM are linked as the real occupation of the
 matrix cells cannot be deduced without some kind of preprocessing


@@ -674,7 +674,7 @@ detection can be done either on the CPU or the GPU but it requires a
 global view on the system execution.
 
 In the first case, when the CPU controls the GPU simulation process,
 global view on the system execution.
 
 In the first case, when the CPU controls the GPU simulation process,

-the dectection is done in two steps: (i) the CPU starts the execution
+the detection is done in two steps: (i) the CPU starts the execution

 of a simulation step on the GPU, (ii) the CPU retrieves the GPU data
 and determines if another iteration must be launched or if the
 simulation has terminated. This approach allows a fine-grain control
 of a simulation step on the GPU, (ii) the CPU retrieves the GPU data
 and determines if another iteration must be launched or if the
 simulation has terminated. This approach allows a fine-grain control


@@ -724,9 +724,9 @@ performance indicator.
 
 The two last implementations -- \textbf{GPU 4.0} and \textbf{GPU 5.0}
 -- illustrate the gain provided by a better usage of the hardware
 
 The two last implementations -- \textbf{GPU 4.0} and \textbf{GPU 5.0}
 -- illustrate the gain provided by a better usage of the hardware

-resources, thanks to the driver execution overlaping capabilities. A
+resources, thanks to the driver execution overlapping capabilities. A

 sequential version of the MIOR algorithm, labeled as \textbf{CPU}, is
 sequential version of the MIOR algorithm, labeled as \textbf{CPU}, is

-provided for comparison purpose. This sequential version is developped
+provided for comparison purpose. This sequential version is developed

 in Java, the same language used for GPU implementations and the Sworm
 model.
 
 in Java, the same language used for GPU implementations and the Sworm
 model.
 


@@ -838,7 +838,7 @@ hardware limits are reached. This indicates that the cost of preparing
 and launching kernels become negligible compared to the computing
 time once a good GPU occupation rate is achieved.
 
 and launching kernels become negligible compared to the computing
 time once a good GPU occupation rate is achieved.
 

-\section{Analysis and recommandations}
+\section{Analysis and recommendations}

 \label{ch17:analysis}
 
 In this section we synthesize the observations done on the two models
 \label{ch17:analysis}
 
 In this section we synthesize the observations done on the two models


@@ -855,7 +855,7 @@ take into account considerations such as the cost of the different
 parts of the algorithm and the expected gains.
 
 In the case of the Collembola model two steps of the algorithm were
 parts of the algorithm and the expected gains.
 
 In the case of the Collembola model two steps of the algorithm were

-ported to GPU. Both steps use straighforward, easily-parallelizable,
+ported to GPU. Both steps use straightforward, easily-parallelizable,

 operations where a direct gain can be expected by using more
 executions cores without important modifications of the algorithm.
 
 operations where a direct gain can be expected by using more
 executions cores without important modifications of the algorithm.
 


@@ -863,10 +863,10 @@ In the MIOR model case however no such inherently parallelizable parts
 are evident in the original sequential algorithm. This is mainly
 explained by the rate of interactions between agents in this model in
 the form of many operations (breathing, growth) on shared carbon
 are evident in the original sequential algorithm. This is mainly
 explained by the rate of interactions between agents in this model in
 the form of many operations (breathing, growth) on shared carbon

-ressources. In this case the algorithm had to be more profundly
+resources. In this case the algorithm had to be more profoundly

 modified while keeping in head the need to remain true to the original
 model, to synchronize the main execution step of all agents in the
 modified while keeping in head the need to remain true to the original
 model, to synchronize the main execution step of all agents in the

-model, to ensure enquity, and to minimize the numbers of
+model, to ensure equity, and to minimize the numbers of

 synchronizations. The minimization is done by factoring the repartition of
 carbon in the model in two separated step at the beginning and the end
 of each iterations rather than at multiple point of the execution.
 synchronizations. The minimization is done by factoring the repartition of
 carbon in the model in two separated step at the beginning and the end
 of each iterations rather than at multiple point of the execution.


@@ -892,8 +892,8 @@ This workflow works well if the considered data transfer time is
 negligible compared to GPU execution or can be done in parallel,
 thanks to the asynchronous nature of OpenCL. If we are to update the
 MAS model after each iteration then performance risk being
 negligible compared to GPU execution or can be done in parallel,
 thanks to the asynchronous nature of OpenCL. If we are to update the
 MAS model after each iteration then performance risk being

-degratated. This is illustrated in the MIOR model by the fact that the
-speedup observerd on GPU is much more significant for bigger
+degraded. This is illustrated in the MIOR model by the fact that the
+speedup observed on GPU is much more significant for bigger

 simulations, which implies longer GPU execution times. Our solution to
 this problem is to desynchronize the execution of the SMA model and
 its GPU parts by requesting the execution of multiple steps of the
 simulations, which implies longer GPU execution times. Our solution to
 this problem is to desynchronize the execution of the SMA model and
 its GPU parts by requesting the execution of multiple steps of the


@@ -907,9 +907,9 @@ meaningless in regard to GPU usage, copying cost, and actual gain in
 execution time, if the process is not already parallel and costly at
 this scale. In the MIOR and the Collembola models, this is solved by
 executing the computations for all agents of the model at the same
 execution time, if the process is not already parallel and costly at
 this scale. In the MIOR and the Collembola models, this is solved by
 executing the computations for all agents of the model at the same

-time. If the model has hovewer only chronic needs for intensive
+time. If the model has however only chronic needs for intensive

 computations then some kind of batching mechanism is required to store
 computations then some kind of batching mechanism is required to store

-waiting treatements in a queue, until the total sum of waiting
+waiting treatments in a queue, until the total sum of waiting

 computations justify the transfers cost to the GPU platform.
 
 \subsection{Implementation challenges}
 computations justify the transfers cost to the GPU platform.
 
 \subsection{Implementation challenges}


@@ -919,14 +919,14 @@ implementation challenges also occur when implementing an OpenCL
 version of a MAS model, mainly related to the underlying limitations
 of the execution platform.
 
 version of a MAS model, mainly related to the underlying limitations
 of the execution platform.
 

-The first one is the impossibility (except in lastest CUDA versions)
-to dynamicaly allocate memory during execution. This is a problem in
+The first one is the impossibility (except in latest CUDA versions)
+to dynamically allocate memory during execution. This is a problem in

 the case of models where the number of agent can vary during the
 simulation, such as prey-predator models. In this case, the only
 solution is to overestimate the size of arrays or data structures to
 the case of models where the number of agent can vary during the
 simulation, such as prey-predator models. In this case, the only
 solution is to overestimate the size of arrays or data structures to

-accomodate these additionnal individuals, or using the CPU to resize
-data structures when these situations occur. Both approachs require
-to trend either memory or performance and are not always pratical.
+accommodate these additional individuals, or using the CPU to resize
+data structures when these situations occur. Both approaches require
+to trend either memory or performance and are not always practical.

 
 Another limitation is the impossibility to store pointers in data
 structures, we restraint any OpenCL to use only one dimension static
 
 Another limitation is the impossibility to store pointers in data
 structures, we restraint any OpenCL to use only one dimension static


@@ -935,10 +935,10 @@ usage of structures like linked-list, graphs or sparse matrix not
 represented by some combination of static arrays, and can be another
 source of memory or performance losses.
 
 represented by some combination of static arrays, and can be another
 source of memory or performance losses.
 

-In the case of MIOR, this problem is especially exarcebed in the case
-of neighboring storage: both representations consum much more memory
+In the case of MIOR, this problem is especially exacerbated in the case
+of neighboring storage: both representations consume much more memory

 that actually required, since the worst case (all agents have
 that actually required, since the worst case (all agents have

-access to all others agents) has to be taken into account defensivly
+access to all others agents) has to be taken into account defensively

 when dimensioning the data structure.
 
 The existence of different generations of GPU hardwares is also a
 when dimensioning the data structure.
 
 The existence of different generations of GPU hardwares is also a


@@ -948,8 +948,8 @@ and requires very regular access patterns to perform efficiently. MAS
 having many random accesses, such as MIOR, or many small global memory
 accesses, such as Collembola, are penalized on these older
 cards. Fortunately, these requirements are less present is modern
 having many random accesses, such as MIOR, or many small global memory
 accesses, such as Collembola, are penalized on these older
 cards. Fortunately, these requirements are less present is modern

-cards, which offer caches and other facilities traditionnaly present
-on CPU to offset these kind of penalities.
+cards, which offer caches and other facilities traditionally present
+on CPU to offset these kind of penalties.

 
 The final concern is related to the previous ones and often result in
 more memory consumption. The amount of memory available on GPU cards
 
 The final concern is related to the previous ones and often result in
 more memory consumption. The amount of memory available on GPU cards


@@ -967,7 +967,7 @@ As shown in the previous sections, many data representations choices
 are common to entire classes of MAS. The paradigm of grid, for example,
 is often encountered in models where each cell constitutes either the
 elementary unit of simulation (SugarScape~\cite{Dsouza2007}) or a
 are common to entire classes of MAS. The paradigm of grid, for example,
 is often encountered in models where each cell constitutes either the
 elementary unit of simulation (SugarScape~\cite{Dsouza2007}) or a

-discretisation of the environment space
+discretization of the environment space

 (Pathfinding~\cite{Guy09clearpath}). These grids can be considered as
 two or three-dimensional matrices, whose processing can be directly
 distributed.
 (Pathfinding~\cite{Guy09clearpath}). These grids can be considered as
 two or three-dimensional matrices, whose processing can be directly
 distributed.


@@ -976,25 +976,25 @@ Another common data representation encountered in MAS system is the
 usage of 2d or 3d coordinates to store the position of each agent of
 the model. In this case, even if the environment is no longer
 discrete, the location information still imply computations
 usage of 2d or 3d coordinates to store the position of each agent of
 the model. In this case, even if the environment is no longer
 discrete, the location information still imply computations

-(euclidian distances) which can be parallelized.
+(euclidean distances) which can be parallelized.

 
 

-MCSMA~\cite{lmlm+13:ip} is a framework developped to provide to the MAS designer
+MCSMA~\cite{lmlm+13:ip} is a framework developed to provide to the MAS designer

 those basic data structures, and the associated operations, to
 facilitate the portage of existing MAS on GPU. Two levels of
 those basic data structures, and the associated operations, to
 facilitate the portage of existing MAS on GPU. Two levels of

-utilization are provided to the developper, depending on its usage
+utilization are provided to the developer, depending on its usage

 profile.
 
 \begin{itemize}
 profile.
 
 \begin{itemize}

-\item A high-level library, constitued of modules regrouping classes
+\item A high-level library, constituted of modules regrouping classes

   of operations. A module provides multiple methods of
   distance computations in 1d, 2d or 3d grids, another one the
   diffusion algorithm...
   of operations. A module provides multiple methods of
   distance computations in 1d, 2d or 3d grids, another one the
   diffusion algorithm...

-\item A low level API which allows the developped direct access to the
+\item A low level API which allows the developed direct access to the

   GPU and the inner working of MCSMA, to develop its own module in
   the case where the required operations are not yet provided by the platform.
 \end{itemize}
 
   GPU and the inner working of MCSMA, to develop its own module in
   the case where the required operations are not yet provided by the platform.
 \end{itemize}
 

-Both usage levels were illustrated in the above two pratical cases. In
+Both usage levels were illustrated in the above two practical cases. In

 MIOR, the whole algorithm (baring initialization) is ported on GPU as
 a specific plugin which allows executing $n$ MIOR simulations and
 retrieve their results. This first approach requires extensive
 MIOR, the whole algorithm (baring initialization) is ported on GPU as
 a specific plugin which allows executing $n$ MIOR simulations and
 retrieve their results. This first approach requires extensive


@@ -1006,7 +1006,7 @@ is not modified and GPU execution is only applied to specific parts of
 the execution which may benefit from it. These two programming
 approaches allow incremental adaptations of existing Java MAS to
 accelerate their execution on GPU, while retaining the option to
 the execution which may benefit from it. These two programming
 approaches allow incremental adaptations of existing Java MAS to
 accelerate their execution on GPU, while retaining the option to

-develop their own reusable or more efficeint module to supplement the
+develop their own reusable or more efficient module to supplement the

 already existing ones.
 
 \section{Conclusion}
 already existing ones.
 
 \section{Conclusion}


@@ -1041,7 +1041,7 @@ lists. Another goal is to provide easier means to control the
 distribution of specific processes between CPU or GPU, to allow the
 easy exploitation of the strengths of each platform in the same
 multi-agent simulation. We think that the same approach, i.e
 distribution of specific processes between CPU or GPU, to allow the
 easy exploitation of the strengths of each platform in the same
 multi-agent simulation. We think that the same approach, i.e

-developping specific environments that facilitate the developper
+developing specific environments that facilitate the developer

 access to the GPU power, can be applied in many domains with
 compute intensive needs to open the GPU use to a larger community. 
 
 access to the GPU power, can be applied in many domains with
 compute intensive needs to open the GPU use to a larger community.