## 6 Experimental Results
### Speedup Analysis  
Let us note that, after executing our PSO skeletons for the same number of iterations as those used in [39], there is still margin for improving results further, specially for the hardest problem (\(f_{8}\)). In Table 3 we depict results for \(f_{8}\) for higher numbers of iterations. They illustrate that better solutions are found after iteration \(9000\) indeed. Next we present the speedups obtained by using our skeletons. In order to analyze their parallel performance, we use two computers which are connected through the intranet of our university and are physically located in different buildings. Both computers use the same Linux distribution (Debian), the same MPI library (OpenMPI 1.4.2), and have analogous Intel Core i3 Duo processors. Thus, we perform parallel experiments with up to four cores. Among the 16 problems presented in our previous experiments, we select the hardest one (\(f_{8}\)) because it requires the longest execution time to obtain good solutions. Thus, it is more likely to improve its time performance by taking advantage of a parallel execution. We conducted two experiments. In the first one, algorithms are run for 50,000 iterations, and in the second they are executed for 200,000 iterations. For each case, we use two different skeletons: the one presented in Section 5.2 (FPS A, standing for _Functional Particle Swarm_), and the final modified version presented in Section 5.3 (FPS B). Since the parallel environment is homogeneous, trying to take advantage of the first skeleton implemented in Section 5.3 to compensate different processors speed would not provide any advantage in this case. In experiments with 50,000 iterations, FPS A updates the global optimum every 500 iterations and does so 100 times, whereas FPS B updates the global optimum every 500 steps for the first 10 times, and next it updates it every 5000 iterations 9 times. In experiments with 200,000 iterations, FPS A updates the optimum every 5000 iterations and does it 40 times, whereas FPS B updates the global optimum every 5000 steps for the first 10 times, and next it updates it every 50,000 steps 3 times. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Function** & **Iterations** & **Best Sol** & **Arith Mean** & **Std Dev** \\ \hline \(f_{8}(x)\) & \(9000\) & \(-12,095.73\) & \(-9686.99\) & \(1362.44\) \\ \(f_{8}(x)\) & \(50,000\) & \(-12,214.17\) & \(-10,339.49\) & \(1062.38\) \\ \(f_{8}(x)\) & \(200,000\) & \(-12,569.48\) & \(-11,091.23\) & \(1011.68\) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Solutions found with different number of iterations. Each parallel skeleton is executed for up to four processors, and the speedup is computed by comparing its execution time with the time of the sequential version. Table 4 summarizes the execution time (in seconds) and the speedup obtained for each input problem and for each skeleton. As it can be expected, FPS B obtains better results than FPS A, as it reduces the communications among processes. The difference between both skeletons is small in the case of the largest execution (\(3.78\)_vs._\(3.76\) speedup with \(4\) processors), but it is more significant in the case of the shortest one (\(3.29\)_vs._\(2.93\)). The reason is that the impact of communications in the largest execution is already small in FPS A, so there is small room for improvement for FPS B. However, in the case of the shortest execution, communications take place more often (in relative terms) so their impact is higher. The speedup of experiments is graphically compared in Figure 3.