measurements to compute the scaling factor values for each processor. This
operation, measurements and computing new scaling factor, can be repeated as
much as needed if the iterations are not regular. Kimura, Peraza, Yu-Liang et
-al.~\cite{11,2,31} used learning methods to select the appropriate scaling
+al.~\cite{11,2,31} used varied heuristics to select the appropriate scaling
factor values to eliminate the slack times during runtime. However, as seen
in~\cite{39,19}, machine learning methods can take a lot of time to converge
when the number of available gears is big. To reduce the impact of slack times,
\item It is well adapted to distributed architectures because it takes into
account the communication time.
\item It is well adapted to distributed applications with imbalanced tasks.
-\item it has very small footprint when compared to other methods
+\item It has very small footprint when compared to other methods
(e.g.,~\cite{19}) and does not require profiling or training as
in~\cite{38,34}.
\end{enumerate}
leads to 18 run states for each program. We use seven MPI programs of the NAS
parallel benchmarks: CG, MG, EP, FT, BT, LU and SP. Figure~(\ref{fig:pred})
presents plots of the real execution times and the simulated ones. The maximum
-normalized error between these two execution times varies between
-\np{0.0073}\AG[]{unit?} to \np{0.031} dependent on the executed benchmark. The
-smallest prediction error was for CG and the worst one was for LU.
+normalized error between these two execution times varies between \np{0.0073} to
+\np{0.031} dependent on the executed benchmark. The smallest prediction error
+was for CG and the worst one was for LU.
\subsection{The experimental results for the scaling algorithm }