\select@language {french}
\select@language {french}
\select@language {french}
\select@language {english}
\select@language {french}
\addvspace {10pt}
\select@language {english}
\addvspace {10pt}
\contentsline {figure}{\numberline {2.1}{\ignorespaces Illustration of the Google, Hadoop and Microsoft technology stacks for cloud applications building. For each stack, the DSL Level, the Execution Level and the Storage Level are detailed. In this scheme, SQL is also described as a stack in which the three levels are merged together and cannot be used independently.}}{29}
\addvspace {10pt}
\addvspace {10pt}
\contentsline {figure}{\numberline {4.1}{\ignorespaces Multiple scenarii of message processing that impact the BlobStorage}}{76}
\contentsline {figure}{\numberline {4.2}{\ignorespaces Distribution scheme of our BitTreeCounter. In the current situation, the tasks $\{3, 12, 18, 23\}$ are not yet completed. The bit arrays of the corresponding leaves ($N(0,3)$, $N(3,3)$ and$ N(5,3)$) are therefore not yet filled with $0$. When the task $23$ will be completed, the node $N(5,3)$ will be updated accordingly. Since its bit array will then become filled with $0$, the node $N(2,2)$ will then be updated, which will in turn lead to the update of node $N(0,1)$. Once the tasks $\{3, 12, 18, 23\}$ are completed, the root node $N(0,1)$ will be filled with $0$ and the BitTreeCounter then returns true to lift the synchronization barrier.}}{82}
\addvspace {10pt}
\contentsline {figure}{\numberline {5.1}{\ignorespaces This non-realistic scheme of the merging prototype logic highlights the tree structure of many MPI primitives. To begin with, the first worker sends a data chunk to the second worker, while the third worker sends simultaneously its data chunk to the fourth worker. A second step follows the first one in which the merging result of the first and second workers are sent to the fourth worker that already owns the merging result of the third and fourth workers. In two steps, the data chunks of the four workers are merged. }}{94}
\contentsline {figure}{\numberline {5.2}{\ignorespaces Distribution scheme of our cloud-distributed Batch K-Means. The communications between workers are conveyed through the BlobStorage. The recalculation phase is a two-step process run by the partial reducers and the final reducer to reduce I/O contention.}}{100}
\contentsline {figure}{\numberline {5.3}{\ignorespaces Time to execute the Reduce phase per unit of memory ($2T_{Blob}^{read} + T_{Blob}^{write}$) in $~10^{-7}$sec/Byte in function of the number of communicating units.}}{110}
\contentsline {figure}{\numberline {5.4}{\ignorespaces Charts of speedup performance curves for our cloud Batch K-Means implementation with different data set size. For a given size $N$, the speedup grows with the number of processing units until $M^{*}$, then the speedup slowly decreases.}}{113}
\contentsline {figure}{\numberline {5.5}{\ignorespaces Charts of speedup performance curves for our cloud Batch K-Means implementation with different number of processing units. For each value of $M$, the value of $N$ is set accordingly so that the processing units are heavy loaded with data and computations. When the number of processing units grows, the communication costs increase and the spread between the obtained speedup and the theoretical optimal speedup increases.}}{114}
\contentsline {figure}{\numberline {5.6}{\ignorespaces Distribution of the processing time (in second) for multiple runs of the same computation task for a single VM. As expected, the distribution is concentrated around a specific value.}}{115}
\contentsline {figure}{\numberline {5.7}{\ignorespaces Distribution of the processing time (in second) for multiple runs of the same computation task for multiple VM. One can note the ``3 modes'' distribution and outliers (tasks run in much more time).}}{116}
\addvspace {10pt}
\contentsline {figure}{\numberline {6.1}{\ignorespaces Plots of the six basic cubic $B$-spline functions with ten uniform knots: $x_0 =0, \ldots , x_9 =9$ ($n =3$, $\chi =10$).}}{125}
\contentsline {figure}{\numberline {6.2}{\ignorespaces Plot of a cubic $B$-spline, a linear combination of the basic $B$-splines plotted in Figure \ref {fig:BasicBSplines}}}{126}
\contentsline {figure}{\numberline {6.3}{\ignorespaces Plot of four splines centers with orthogonal coefficients: $\overline {B}_1, \ldots , \overline {B}_4$ where $G = 1500$, $d=1500$, $\chi = 50$, $sc =10$.}}{127}
\contentsline {figure}{\numberline {6.4}{\ignorespaces Plot of two independent realizations of the random variable $\textbf {Z}$ defined by equation \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:randomVariable}\unskip \@@italiccorr )}}: $\overline {B_1}, \ldots , \overline {B_4}$ where $G = 1500$, $d=1500$, $\chi = 50$, $sc =10$.}}{127}
\contentsline {figure}{\numberline {6.5}{\ignorespaces Illustration of the parallelization scheme of VQ procedures described by equations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:averaging}\unskip \@@italiccorr )}}. The prototypes versions are synchronized every $\tau $ points.}}{130}
\contentsline {figure}{\numberline {6.6}{\ignorespaces Charts of performance curves for iterations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:averaging}\unskip \@@italiccorr )}} with different numbers of computing entities: $M=1,2,10$. The three charts correspond to different values of $\tau $ which is the integer that characterizes the frequency of the averaging phase ($\tau =1,10,100$).}}{132}
\contentsline {figure}{\numberline {6.7}{\ignorespaces Illustration of the parallelization scheme of VQ procedures described by equations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:correctAveraging}\unskip \@@italiccorr )}}.}}{134}
\contentsline {figure}{\numberline {6.8}{\ignorespaces Charts of performance curves for iterations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:correctAveraging}\unskip \@@italiccorr )}} with different numbers of computing entities, $M=1,2,10$. The three charts correspond to different values of $\tau $ ($\tau =1,10,100$).}}{136}
\contentsline {figure}{\numberline {6.9}{\ignorespaces Illustration of the parallelization scheme described by equations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:delayedAveraging}\unskip \@@italiccorr )}}. The reducing phase is only drawn for processor $1$ where $t=2\tau $ and processor $4$ where $t=4\tau $.}}{137}
\contentsline {figure}{\numberline {6.10}{\ignorespaces Charts of performance curves for iterations \textup {\hbox {\mathsurround \z@ \normalfont (\ignorespaces \ref {eq:delayedAveraging}\unskip \@@italiccorr )}} with different numbers of computing entities, $M=1,2,10$. The three charts correspond to different values of $\tau $ ($\tau =1,10,100$).}}{138}
\addvspace {10pt}
\contentsline {figure}{\numberline {7.1}{\ignorespaces Overview of the interaction between ProcessService instances and the instance of ReduceService. All the communications are made through the BlobStorage: ReduceService gets the blobs put by the ProcessService instances while they retrieve the computation of the ReduceService.}}{144}
\contentsline {figure}{\numberline {7.2}{\ignorespaces Overview of the ReduceService instance processing the ``reducing task''. This QueueService builds the shared version by computing the sum of all the available displacement terms sent by the ProcessService instances in the BlobStorage.}}{145}
\contentsline {figure}{\numberline {7.3}{\ignorespaces Overview of the ProcessService. Each triangle stands for a specific thread (process thread, push thread and pull thread). The arrows describe read/write actions: the tail of a blue dashed arrow is read by the entity at its head and the entity at the tail of a red solid arrow makes update on the entity that lies at its head. The push thread and the pull thread enable communications between the process thread and the BlobStorage. The process thread alternatively performs three actions (process action $1,2,3$). Process action 1 replaces the local version of the prototypes by the sum of the latest shared version (kept in the read buffer) and a displacement term. Process action 2 uses data to execute VQ iterations and updates both the local version and the displacement term. Process action 3 moves the displacement term to a dedicated buffer (write buffer) and pushes its content to the BlobStorage.}}{147}
\contentsline {figure}{\numberline {7.4}{\ignorespaces Normalized quantization curves with $M=1,2,4,8,16$. Our cloud DAVQ algorithm has good scalability properties up to $M=8$ instances of the ProcessService. Troubles appear with $M=16$ because the ReduceService is overloaded.}}{149}
\contentsline {figure}{\numberline {7.5}{\ignorespaces Normalized quantization curves with $M=8,16,32,64$ instances of ProcessService and with an extra layer for the so called ``reducing task''. Our cloud DAVQ algorithm has good scalability properties for the quantization performance up to $M=32$. However, the algorithm behaves badly when the number of computing instances is raised to $M=64$.}}{151}
\contentsline {figure}{\numberline {7.6}{\ignorespaces Overview of the reducing procedures with two layers: \newline the PartialReduceService and the FinalReduceService.}}{151}
\contentsline {figure}{\numberline {7.7}{\ignorespaces These charts plot the number of points processed as time goes by. The top chart shows the curves associated to $M=1,2,4,8$ with one layer for the reducing task whereas at the bottom a second layer is added and $M=8,16,32,64$.}}{153}
\contentsline {figure}{\numberline {7.8}{\ignorespaces This chart plots the number of points processed in a given time span ($3600$ seconds) for different values of $M$ ($M=1,2,4,8,16,32,64$). The reducing task is composed of one layer for $M=1,2,4$ and two layers for $M=8,16,32,64$. We can observe a linear scalability in terms of point processed by the system up to $M=64$ computing instances.}}{154}
\contentsline {figure}{\numberline {7.9}{\ignorespaces These charts report on the competition between our cloud DAVQ algorithm and the cloud Batch K-Means. The graphs show the empirical distortion of the algorithm over the time. The empirical distortion is computed using the shared version for our cloud DAVQ algorithm while it is computed during the synchronization phase (all mappers receiving the same prototypes) for the cloud Batch K-Means. In these experiments the cloud DAVQ algorithm outperforms the cloud Batch K-Means: the same quantization level is obtained within a shorter period.}}{155}
\select@language {french}
\addvspace {10pt}
\addvspace {10pt}
\select@language {english}
