ProPE PE Process - Revision history

Robert-schade-e757@uni-paderborn.de at 11:28, 19 July 2024

2024-07-19T11:28:28Z

Daniel-schurhoff-de23@rwth-aachen.de at 08:27, 5 September 2019

2019-09-05T08:27:04Z

Daniel-schurhoff-de23@rwth-aachen.de at 08:26, 5 September 2019

2019-09-05T08:26:53Z

Stefan-erlbeck-05df@rwth-aachen.de at 15:17, 20 March 2019

2019-03-20T15:17:43Z

Nina-loseke-fd7a@rwth-aachen.de: /* B. OpenMP behavior */

2019-01-24T14:52:39Z

B. OpenMP behavior

Nina-loseke-fd7a@rwth-aachen.de: /* B. OpenMP behavior */

2019-01-24T14:51:59Z

B. OpenMP behavior

Nina-loseke-fd7a@rwth-aachen.de at 12:23, 24 January 2019

2019-01-24T12:23:43Z

Show changes

Nina-loseke-fd7a@rwth-aachen.de at 07:39, 24 January 2019

2019-01-24T07:39:25Z

Jan-eitzinger-77c0@uni-erlangen.de: /* Optimization */

2019-01-16T11:55:26Z

Optimization

Jan-eitzinger-77c0@uni-erlangen.de: /* Optimization */

2019-01-16T11:54:54Z

Optimization

← Older revision		Revision as of 11:28, 19 July 2024
Line 1:		Line 1:
	[[Category:HPC-Developer]]		[[Category:HPC-Developer]]
		+	[[Category:Benchmarking]]<nowiki />
		+
	== Introduction ==		== Introduction ==

← Older revision		Revision as of 08:27, 5 September 2019
Line 1:		Line 1:
−	[[HPC-Developer]]	+	[[Category:HPC-Developer]]
	== Introduction ==		== Introduction ==

← Older revision		Revision as of 08:26, 5 September 2019
Line 1:		Line 1:
		+	[[HPC-Developer]]
	== Introduction ==		== Introduction ==

@@ Line 230: / Line 230: @@
 '''Detailed Metrics:'''
-* '''I/O Bandwidth''' is calculated as the percentage of the measured I/O badwidth of the application to the maximum possible I/O bandwith on the system. The threshold is 80%.
+* '''I/O Bandwidth''' is calculated as the percentage of the measured I/O bandwidth of the application to the maximum possible I/O bandwith on the system. The threshold is 80%.
 <math>

@@ Line 113: / Line 113: @@
 ==== B. OpenMP behavior ====
-For a deeper analysis of an application on OpenMP level you can use the tools [[Intel_VTune|Intel VTune]] or [[Likwid|LIKWID]]. The tools like Score-P and Extrae also partially support the analysis of some OpenMP applications. We recommend to analyze your application on only one compute node for a test case, which runs about 5-20 minutes.
+For a deeper analysis of an application on OpenMP level you can use the tools [[Intel_VTune|Intel VTune]] or [[Likwid|LIKWID]]. The tools like [[Score-P]] and Extrae also partially support the analysis of some OpenMP applications. We recommend to analyze your application on only one compute node for a test case, which runs about 5-20 minutes.
 '''Detailed Metrics:'''

@@ Line 3: / Line 3: @@
 The performance engineering process presented here is a prescription, how to analyze and to tune performance of an application step by step. We assume, that the used algorithm in the analyzed application is already efficient enough for the  to solved problem.  However, some small algorithmic improving recommendations can be provided.
-With this process the most performance problem of an application can be recognized. However, some problems can be identified only by experts. The results of below presented analysis will be then a good start point for fast understanding of program performance.
+With this process the most significant performance problem of an application can be recognized. However, some problems can be identified only by experts. The results of below presented analysis will be then a good starting point for fast understanding of program performance.
 == PE-Process Overview ==
-Performance of an application is a combination of several aspects. For succesfully improving of application performance all performance aspects should be analized and optimized, if needed.
+Performance of an application is a combination of several aspects. For succesfully improving the application performance, all performance aspects should be analyzed and optimized, if needed.
-We differentiate among four performance aspects:
+We differentiate between four performance aspects:
 '''A'''. MPI behavior: communication and synchronization among MPI processes on multiple compute nodes.
@@ Line 19: / Line 19: @@
 '''D'''. Input/Output overhead: how dominant  reading and writing of the data in the application is and how this impacts the full program performance
-The PE processes consists of three repetitive steps: overview analysis, detailed analysis of one of the performance aspects and optimization of this performance aspect. Each analysis delivers some metrics, based on which several permance issues can be recognized and optimized. If an optimization of one of the performance aspects was performed, the performance engineering process should be started from the beginning to focus on optimization of the next performance aspect, which is identified by the subsequent analysis.
+The PE process consists of three repetitive steps: overview analysis, detailed analysis of one of the performance aspects and optimization of this performance aspect. Each analysis delivers some metrics, based on which several performance issues can be recognized and optimized. If an optimization of one of the performance aspects was executed, the performance engineering process should be started from the beginning to focus on optimization of the next performance aspect, which is identified by the subsequent analysis.
 [[File:ProPE-PE-workflow.png|900px]]
@@ Line 25: / Line 25: @@
 === Overview Analysis ===
-At first we start with a rough overview of the application performance for all four aspects with light weight analysis tools like
+At first we start with a rough overview of the application performance for all four aspects with light-weight analysis tools like
 [https://software.intel.com/sites/products/snapshots/application-snapshot/ Intel Application Performance Snapshot] (free) or
-[https://www.arm.com/products/development-tools/hpc-tools/cross-platform/performance-reports Arm Performance Reports] (commercial). By both tools a new compilation and linking of the program or special settings of the tool are not needed. The tools give no detailed information about single functions, but provide concrete numbers, like time share spent in MPI operations, in OpenMP synchronization or number of executed instructions per cycle etc., with a threshold for each performance aspect. We call these numbers '''metrics'''. Thresholds for all metrics have been defined by experts from corresponding HPC area or set by analysis tools. From each metric and its threshold it can be recognized, which aspect is a performance bottleneck for the application. This performance aspect should then be analyzed in detail and optimized at first in the next performance engineering steps.
+[https://www.arm.com/products/development-tools/hpc-tools/cross-platform/performance-reports Arm Performance Reports] (commercial). For both tools a new compilation and linking of the program or special settings of the tool are not needed. The tools give no detailed information about single functions, but provide concrete numbers, like time share spent in MPI operations, in OpenMP synchronization or number of executed instructions per cycle etc., with a threshold for each performance aspect. We call these numbers '''metrics'''. Thresholds for all metrics have been defined by experts from the corresponding HPC area or set by analysis tools. Based on each metric and its threshold it can be recognized, which aspect is a performance bottleneck for the application. This performance aspect should then be analyzed in detail and optimized at first in the next performance engineering steps.
 ==== Metrics and their thresholds: ====
@@ Line 41: / Line 41: @@
 === Deeper Analysis ===
-By the overview analysis a performance aspect is identified, that should be analyzed deeper. First, the application structure should be well understood by identifying of the main temporal phases (initialization, iterative loop, etc.). Next, it would be good to focus the analysis on a selected region to avoid that the initialization phase perturbs the metrics for the execution in cases where only few iterations are executed. It is also helpful to understand the internal structure of the selected region (number of iterations, phases within the iteration, etc.).  In a following analysis some '''detailed metrics''' should be calculated for the selected application region. For each performance aspect the detailed metrics are listed here. These metrics should be calculated to identify the performance issues. We call identified performance issues  issues patterns. Patterns can be recognized by well defined metrics and are listed below in step 3.Optimization for each performance aspect.
+By the overview analysis a performance aspect is identified, that should be analyzed deeper. First, the application structure should be well understood by identifying the main temporal phases (initialization, iterative loop, etc.). Next, it would be good to focus the analysis on a selected region to avoid that the initialization phase perturbs the metrics for the execution in cases where only few iterations are executed. It is also helpful to understand the internal structure of the selected region (number of iterations, phases within the iteration, etc.).  In a following analysis some '''detailed metrics''' should be calculated for the selected application region. For each performance aspect the detailed metrics are listed here. These metrics should be calculated to identify the performance issues. We call identified performance issues patterns. Patterns can be recognized by well-defined metrics and are listed below in step 3.Optimization for each performance aspect.
 ====  A. MPI behavior ====

@@ Line 242: / Line 242: @@
 '''A'''. Issues Patterns on MPI Level
-[[File:ProPe-PE-MPI-tab.png]]
+[[File:ProPe-PE-MPI-tab.png|900px]]
 '''B'''. Issues Patterns for OpenMP Level
-[[File:Prope-PE-OpenMP-tab.png]]
+[[File:Prope-PE-OpenMP-tab.png|900px]]
 '''C'''. Issues Patterns for Node-level
-[[File:Prope-PE-Nodelevel-tab.png]]
+[[File:Prope-PE-Nodelevel-tab.png|900px]]