## 5 Experiments
### Analysis of the Results
\begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Program**} & \multirow{2}{*}{**Runtime**} & \multicolumn{8}{c}{**Speedup for Computing Processes [s]**} \\ \cline{3-10}  & & **1** & **2** & **4** & **8** & **16** & **32** & **64** & **128** & **256** \\ \hline \multirow{3}{*}{DAC} & Docker & 1.00 & 1.95 & 3.81 & 7.55 & 14.94 & 28.71 & 51.08 & 47.65 & 48.65 \\ \cline{2-10}  & Host & 1.00 & 1.95 & 3.81 & 7.56 & 14.91 & 29.04 & 54.69 & 53.47 & 55.20 \\ \hline \multirow{3}{*}{MasterSlave} & Docker & 1.00 & 1.95 & 3.81 & 7.53 & 14.85 & 28.47 & 48.67 & 45.60 & 37.80 \\ \cline{2-10}  & Host & 1.00 & 1.95 & 3.81 & 7.53 & 14.84 & 28.67 & 52.39 & 48.62 & 42.78 \\ \hline \multirow{3}{*}{SPMD} & Docker & 1.00 & 1.96 & 3.83 & 7.49 & 14.11 & 27.51 & 50.50 & 60.91 & 21.66 \\ \cline{2-10}  & Host & 1.00 & 1.96 & 3.82 & 7.43 & 13.97 & 27.29 & 50.44 & 69.94 & 21.66 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Speed-up execution time of programs for computing processes. Figure 13: Speed-up execution time of programs for computing processes. time do not generate too much overhead that could make the total execution time larger. Generally, for the oversubscription scenario, in our case, 256 processes, we expect additional times due to context switching although in some cases, additional processes (or threads) could hide communication latency. In the specific cases of our applications, we shall note various communication schemes that affect the execution times and scalability. Speed-up numbers will be specific to particular applications as they depend mainly on the ratio of time spent on computations to the time of communication. For master-slave, this will depend on the subrange size and assumed accuracy of its integration, for geometric SPMD--on the number and complexity of computations performed on a subdomain of a given size, for the divide-and-conquer application--on the size of the initial vector, number of processes and consequently size of a subvector assigned to a process in the leaf of the divide-and-conquer tree. On the other hand, execution times and speed-ups are affected by the communication schemes in these application paradigms and the possibility of parallel communication between pairs of processes. It should be noted that generally, for a given input data size and increasing number of processes, the ratio of computational time to the communication time decreases because the communication time includes the constant component of start-up time [9]. For the master-slave code, we see the maximum speed-up using physical cores (64) and because of the star master-slaves communication pattern in this case, the master process might become a bottleneck for a larger number of processes. For the stencil computations (geometric SPMD) and the 3D domain, each process communicates with a limited number of neighbors which allows for parallel inter-process communication and obtaining highest speed-up for 128 processes using all logical cores. For divide-and-conquer pairs of processes operating at the same level of the divide-and-conquer tree, they can operate in parallel. Here, we see similar speed-up values for 64, 128 and 256 processes. We should note that an MPI implementation can optimize communication between processes running on one node using shared memory, especially for divide-and-conquer and neighboring processes on the same node that explains observed results. Additionally, we observe that for all the applications and highest obtained speed-ups we see a consistent difference in favor of the host versus Docker versions, i.e., 3.6 for divide-and-conquer, 3.7 for master-slave and 9 for geometric SPMD. Now, considering the preferred compilation flags, run times for each program on Docker and on the Host can be compared.