]> AND Private Git Repository - mpi-energy2.git/commitdiff
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
Subsection C have been corrected. There are still a lot of errors!
authorjean-claude <jean-claude.charr@univ-fcomte.fr>
Wed, 14 Oct 2015 14:00:49 +0000 (16:00 +0200)
committerjean-claude <jean-claude.charr@univ-fcomte.fr>
Wed, 14 Oct 2015 14:00:49 +0000 (16:00 +0200)
mpi-energy2-extension/Heter_paper.tex

index 1774eba61645015f7900a0f4a4ea93ed408824c7..bc489f480ed288ab79eb5bcd867d43b1fdd424b0 100644 (file)
@@ -822,20 +822,20 @@ communication ratio.
 
 
  Figure \ref{fig:time_sen} presents the execution times for all the benchmarks over the two scenarios. For most of the benchmarks running over the one site scenario, their execution times are approximately divided by two  when the number of computing nodes is doubled from 16 to 32 nodes (linear speed up according to the number of the nodes).  
 
 
  Figure \ref{fig:time_sen} presents the execution times for all the benchmarks over the two scenarios. For most of the benchmarks running over the one site scenario, their execution times are approximately divided by two  when the number of computing nodes is doubled from 16 to 32 nodes (linear speed up according to the number of the nodes).  
+\textcolor{red}{The transition between the execution times to the performance degradation is not clear}
 
 
 
 
-\textcolor{blue}{
-The performance degradation percentage of EP benchmark is the higher when it is compared with 
-the other benchmarks. There are no communication and slack times in this benchmark and its 
-performance degradation percentage depends on the frequency value selected in the computing node.
-The rest of the benchmarks showed different performance degradation percentages, which are decreased
-when the communication times are increased and vice versa.}
+The performance degradation percentage of the EP benchmark after applying the scaling factors selection algorithm is the highest in comparison to 
+the other benchmarks. Indeed, in the EP benchmark, there are no communication and slack times and its 
+performance degradation percentage only depends on the frequencies values selected by the algorithm for the computing nodes.
+The rest of the benchmarks showed different performance degradation percentages, which decrease
+when the communication times increase and vice versa.
 
 
-\textcolor{blue}{Figure \ref{fig:dist} presents the tradeoff distance percentage between the energy saving  and the performance degradation for all benchmarks  over both  scenarios. The tradeoff distance percentage can be 
-computed as in the tradeoff function \ref{eq:max}. The one site scenario with 16 nodes gives the best energy and performance 
-tradeoff, on average is equal to  26\%. As a result, one site scenario using both 16 and 32 nodes had better energy and performance 
-tradeoff comparing to the two sites scenario. This because the former used high speed local communications 
-which increased the computations to communications ratio  and the latter used long distance communications which decreased this ratio. }   \textcolor{red}{The last paragraph has compared the two scenarios}
+Figure \ref{fig:dist} presents the  distance percentage between the energy saving  and the performance degradation for each benchmark  over both  scenarios. The tradeoff distance percentage can be 
+computed as in equation \ref{eq:max}. The one site scenario with 16 nodes gives the best energy and performance 
+tradeoff, on average it is equal to  26\%. The one site scenario using both 16 and 32 nodes had better energy and performance 
+tradeoff comparing to the two sites scenario  because the former has high speed local communications 
+which increase the computations to communications ratio  and the latter uses long distance communications which decrease this ratio. 
 
 
  Finally, the best energy and performance tradeoff depends on all of the following:
 
 
  Finally, the best energy and performance tradeoff depends on all of the following:
@@ -864,13 +864,17 @@ in the figures \ref{fig:eng-cons-mc} and \ref{fig:time-mc} respectively.
 The execution times for most of  the NAS  benchmarks are higher over the one site multi-cores per node scenario 
  than the execution time of those running over one site single core per node  scenario. Indeed,  
    the communication times  are higher in the one site multi-cores scenario than in the latter scenario because all the cores of a node  share  the same node network link which can be  saturated when running communication bound applications. On the other hand,  the execution times for most of the NAS benchmarks  are lower over 
 The execution times for most of  the NAS  benchmarks are higher over the one site multi-cores per node scenario 
  than the execution time of those running over one site single core per node  scenario. Indeed,  
    the communication times  are higher in the one site multi-cores scenario than in the latter scenario because all the cores of a node  share  the same node network link which can be  saturated when running communication bound applications. On the other hand,  the execution times for most of the NAS benchmarks  are lower over 
-the two sites  multi-cores scenario than those over the two sites one core scenario. 
+the two sites  multi-cores scenario than those over the two sites one core scenario. In the two sites multi-cores scenario, There are three types of communications :
+\begin{itemize}
+\item between cores on the same node via shared memory 
+\item between cores from distinct nodes but belonging to the same cluster or site via local network
+\item between cores from distinct sites via long distance network
+\end{itemize}
+The latency of the communications increases from shared memory to LAN to WAN.
+Therefore, using multi-cores communicating via shared memory
+has reduced the communication times, and thus the overall execution time is also decreased.
+
 
 
-\textcolor{blue}{Furthermore,  in two sites multi-cores per node scenario part of the communications happened via shared memory
-and the rest via long distance network. According to the high latency in the long distance network, the
-communication times are smaller compared to the  communication times of the shared memory. 
-Therefore, using the shared memory communications mixed with the long distance communications 
-has decreased the communication times, and thus the overall execution time is decreased.}
 
 The experiments showed that for most of the NAS benchmarks and between the four scenarios,  
 the one site one core scenario gives the best execution times because the communication times are the lowest. 
 
 The experiments showed that for most of the NAS benchmarks and between the four scenarios,  
 the one site one core scenario gives the best execution times because the communication times are the lowest. 
@@ -879,11 +883,14 @@ Moreover, the energy consumptions of the NAS benchmarks are lower over the
 one site one core scenario  than over the one site multi-cores scenario because 
 the first scenario had less execution time than the latter which results in less static energy being consumed.
 
 one site one core scenario  than over the one site multi-cores scenario because 
 the first scenario had less execution time than the latter which results in less static energy being consumed.
 
-\textcolor{blue}{ 
-Therefore, the computations to communications ratios of the NAS benchmarks are higher over 
-the one site one core scenario  compared to the other scenarios. 
-More energy reduction has achieved when this ratio increased, because the proposed scaling algorithm selecting smaller frequencies that decreased the dynamic power consumption.  Whereas, the energy consumption in the two sites multi-cores scenario is higher than the energy consumption 
-of the two sites one core scenario. Actually, using multi-cores in this scenario decreased the communication times that decreased the static energy consumption.}
+The computations to communications ratios of the NAS benchmarks are higher over 
+the one site one core scenario  when compared to the ratios of the other scenarios. 
+More energy reduction was achieved when this ratio is increased because the proposed scaling algorithm selects smaller frequencies that decrease the dynamic power consumption. 
+
+  \textcolor{red}{ The next sentence is completely false! It is impossible to have these results!  Whereas, the energy consumption in the two sites multi-cores scenario is higher than the energy consumption 
+of the two sites one core scenario. 
+Actually, using multi-cores in this scenario decreased the communication times that decreased the static energy consumption.}
 
 
 These experiments also showed that the energy 
 
 
 These experiments also showed that the energy 
@@ -892,11 +899,10 @@ scenarios  because there are no or small communications,
 which could increase or decrease the static power consumptions. Contrary to EP and MG, the  energy consumptions 
 and the execution times of the rest of the  benchmarks  vary according to the  communication times that are different from one scenario to the other.
 
 which could increase or decrease the static power consumptions. Contrary to EP and MG, the  energy consumptions 
 and the execution times of the rest of the  benchmarks  vary according to the  communication times that are different from one scenario to the other.
 
-\textcolor{blue}{
-The energy saving percentages of all NAS benchmarks running over these four scenarios are presented in the figure \ref{fig:eng-s-mc}. This figure 
-shows that  the energy saving percentages are higher  over the two sites multi-cores scenario 
-than over the two sites one core scenario, on average they are equal to 22\% and 18\%
-respectively. This is according to the increase or decrease in the computations to communications  ratio  as mentioned previously.}
+
+The energy saving percentages of all NAS benchmarks running over these four scenarios are presented in the figure \ref{fig:eng-s-mc}. It shows that  the energy saving percentages   over the two sites multi-cores scenario 
+and over the two sites one core scenario are on average  equal to 22\% and 18\%
+respectively. The energy saving percentages   are higher in the former scenario because  its computations to communications  ratio is higher than the ratio of the latter scenario  as mentioned previously.
 
 
 In contrast, in the one site one 
 
 
 In contrast, in the one site one 
@@ -906,26 +912,27 @@ are a small difference  in the computations to communications ratios, which lead
 the proposed scaling algorithm to select similar frequencies for both scenarios.  
 
 The performance degradation percentages of the NAS benchmarks are presented in
 the proposed scaling algorithm to select similar frequencies for both scenarios.  
 
 The performance degradation percentages of the NAS benchmarks are presented in
-figure \ref{fig:per-d-mc}. 
-
-It indicates that the performance degradation percentages for the NAS benchmarks are higher over the two sites 
+figure \ref{fig:per-d-mc}. It shows that the performance degradation percentages for the NAS benchmarks are higher over the two sites 
 multi-cores scenario than over the  two sites  one core scenario, equal on average to 7\% and 4\% respectively. 
 Moreover, using the two sites multi-cores scenario increased 
 the computations to communications ratio, which may increase 
 the overall execution time  when the proposed scaling algorithm is applied and the frequencies scaled down.  
 
 multi-cores scenario than over the  two sites  one core scenario, equal on average to 7\% and 4\% respectively. 
 Moreover, using the two sites multi-cores scenario increased 
 the computations to communications ratio, which may increase 
 the overall execution time  when the proposed scaling algorithm is applied and the frequencies scaled down.  
 
-\textcolor{blue}{
+
 When the benchmarks are executed  over the one 
 When the benchmarks are executed  over the one 
-site one core scenario their performance degradation percentages, on average
-is equal to 10\%, are higher than those executed over one site multi-cores, 
-which on average is equal to 7\%. This because using  multi-cores in one site scenario
-decreased the computations to communications ratio. Therefore, selecting small 
-frequencies by the scaling algorithm do not increase the execution time significantly.}
+site one core scenario, their performance degradation percentages are equal  on average
+to 10\% and are higher than those executed over the one site multi-cores scenario, 
+which on average is equal to 7\%. 
+
+\textcolor{red}{the next sentence is completely false! 
+The higher performance degradation percentages over the first scenario is due to the use of multi-cores which 
+decreases the computations to communications ratio. Therefore, selecting small 
+frequencies by the scaling algorithm do not increase the execution time significantly. }
+
 
 
-\textcolor{blue}{
 The tradeoff distance percentages of the NAS 
 benchmarks over all scenarios are presented in the figure \ref{fig:dist-mc}.
 The tradeoff distance percentages of the NAS 
 benchmarks over all scenarios are presented in the figure \ref{fig:dist-mc}.
-These  tradeoff distance percentages are used to verified which scenario is the best in term of the energy and performance ratio. The figure indicates that using muti-cores in both of the one site and two sites scenarios gives bigger  tradeoff distance percentages, on overage they are equal to 17.6\% and 15.3\% respectively. On the contrary, using one core per node in both of one site and two sites scenarios gives lower  tradeoff distance percentages, on average they are equal to 14.7\% and 13.3\% respectively. }
+These  tradeoff distance percentages are used to verify which scenario is the best in terms of energy reduction and performance. The figure shows that using muti-cores in both of the one site and two sites scenarios gives bigger  tradeoff distance percentages, on overage equal to 17.6\% and 15.3\% respectively, than using one core per node in both of one site and two sites scenarios,  on average  equal to 14.7\% and 13.3\% respectively. 
 
 \begin{table}[]
 \centering
 
 \begin{table}[]
 \centering