[ 4 / 4 ] Application profile is long enough (15.78 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 0 / 2 ] Too much execution time spent in category "Others" (46.54 %)

If the category "Others" represents more than 20% of the execution time, it means that the application profile misses a representative part of the application. Examine functions details to properly identify “Others” category components. Rerun after adding most represented library names (e.g. more than 20% of coverage) to external_libraries (the names can be directly provided by ONE View)

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (18.95%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 2 / 4 ] A significant amount of threads are idle (36.67%)

On average, more than 10% of observed threads are idle. Such threads are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 2 / 4 ] CPU activity is below 90% (63.45%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 4 / 4 ] Loop profile is not flat

At least one loop coverage is greater than 4% (5.04%), representing an hotspot for the application

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (14.18%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 1 / 4 ] Affinity stability is lower than 90% (47.14%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (74.98%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (4.77%) lower than cumulative innermost loop coverage (14.18%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.07%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (14.13 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 0 / 2 ] Too much execution time spent in category "Others" (28.35 %)

If the category "Others" represents more than 20% of the execution time, it means that the application profile misses a representative part of the application. Examine functions details to properly identify “Others” category components. Rerun after adding most represented library names (e.g. more than 20% of coverage) to external_libraries (the names can be directly provided by ONE View)

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (11.79%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 114.76% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (58.08%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 2.90%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (8.32%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (8.77%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 4 / 4 ] Affinity is good (99.69%)

Threads are not migrating to CPU cores: probably successfully pinned

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (77.33%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (3.01%) lower than cumulative innermost loop coverage (8.77%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.03%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (13.38 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 15.76 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (6.79%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 218.22% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (55.34%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 1.55%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (4.57%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (5.17%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 2 / 4 ] Affinity stability is lower than 90% (64.39%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (80.39%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (1.62%) lower than cumulative innermost loop coverage (5.17%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (13.14 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 8.29 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (3.92%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 423.89% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (53.93%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 0.79%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (2.51%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (3.13%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 2 / 4 ] Affinity stability is lower than 90% (66.39%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (81.11%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.79%) lower than cumulative innermost loop coverage (3.13%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (12.75 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 4.85 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (2.17%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 828.22% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (52.56%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 0.32%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (1.37%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (1.65%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 2 / 4 ] Affinity stability is lower than 90% (67.01%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (84.03%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.52%) lower than cumulative innermost loop coverage (1.65%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (13.08 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 2.22 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (1.31%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 1637.07% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (51.95%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 0.16%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (0.85%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (1.04%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 2 / 4 ] Affinity stability is lower than 90% (68.43%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (86.78%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.27%) lower than cumulative innermost loop coverage (1.04%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (13.21 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 1.90 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (0.92%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 3256.59% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (51.99%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 0.15%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (0.64%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (0.75%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 3 / 4 ] Affinity stability is lower than 90% (89.73%)

Threads are often migrating to other CPU cores/threads. For OpenMP, typically set (OMP_PLACES=cores OMP_PROC_BIND=close) or (OMP_PLACES=threads OMP_PROC_BIND=spread). With OpenMPI + OpenMP, use --bind-to core --map-by node:PE=$OMP_NUM_THREADS --report-bindings. With IntelMPI + OpenMP, set I_MPI_PIN_DOMAIN=omp:compact or I_MPI_PIN_DOMAIN=omp:scatter and use -print-rank-map.

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (88.20%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.17%) lower than cumulative innermost loop coverage (0.75%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)

[ 4 / 4 ] Application profile is long enough (13.39 s)

To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

[ 0 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information

Functions without compilation information (typically not compiled with -g) cumulate 100.00% of the time spent in analyzed modules. Check that -g is present.
Remark: if -g is indeed used, this can also be due to some compiler built-in functions (typically math) or statically linked libraries. This warning can be ignored in that case.

[ 0 / 3 ] Some functions are compiled with a low optimization level (O0 or O1)

To have better performances, it is advised to help the compiler by using a proper optimization level (-O2 of higher). Warning, depending on compilers, faster optimization levels can decrease numeric accuracy.

[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.

[ 0 / 3 ] Compilation of some functions is not optimized for the target processor

Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.81 % of the execution time)

To have a representative profiling, it is advised that the category "Others" represents less than 20% of the execution time in order to analyze as much as possible of the user code

[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated.

[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (0.82%)

If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances.

[ 4 / 4 ] Threads activity is good

On average, more than 4360.28% of observed threads are actually active

[ 2 / 4 ] CPU activity is below 90% (51.94%)

CPU cores are idle more than 10% of time. Threads supposed to run on these cores are probably IO/sync waiting. Some hints: use faster filesystems to read/write data, improve parallel load balancing and/or scheduling.

[ 0 / 4 ] Loop profile is flat

No hotspot found in the application (greatest loop coverage is 0.15%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (0.61%)

[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (0.67%)

If the time spent in analyzed innermost loops is less than 15%, standard innermost loop optimizations such as vectorisation will have a limited impact on application performances.

[ 4 / 4 ] Affinity is good (93.26%)

Threads are not migrating to CPU cores: probably successfully pinned

[ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

[ 0 / 3 ] Too many functions do not use all threads

Functions running on a reduced number of threads (typically sequential code) cover at least 10% of application walltime (88.75%). Check both "Max Inclusive Time Over Threads" and "Nb Threads" in Functions or Loops tabs and consider parallelizing sequential regions or improving parallelization of regions running on a reduced number of threads

[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.15%) lower than cumulative innermost loop coverage (0.67%)

Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex

[ 2 / 2 ] Less than 10% (0.00%) is spend in BLAS2 operations

BLAS2 calls usually could make a poor cache usage and could benefit from inlining.

[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions)