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

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 53.85% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.38 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

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

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 45.00% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.65 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.02 % 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.

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

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 41.67% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.75 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

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

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 43.33% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.70 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

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

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 46.51% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.60 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

[ 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.

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 37.84% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.86 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (79.26%)

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 2247.14% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.41% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (78.51%)

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.53%)

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 (11.84%). 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.75%) lower than cumulative innermost loop coverage (78.51%)

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.89 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 40.91% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.77 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (78.12%)

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 2980.50% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.18% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (77.45%)

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.53%)

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 (10.08%). 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.66%) lower than cumulative innermost loop coverage (77.45%)

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.10 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 44.44% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.67 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (77.08%)

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 3719.61% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.18% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (76.49%)

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.52%)

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 (13.36%). 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.59%) lower than cumulative innermost loop coverage (76.49%)

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 (11.64 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 31.37% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 2.06 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (75.87%)

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 4451.01% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.10% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (75.32%)

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.48%)

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 (15.21%). 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.55%) lower than cumulative innermost loop coverage (75.32%)

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 (11.19 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 46.34% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.61 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.01 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (75.72%)

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 5184.95% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.18% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (75.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.

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

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 (19.27%). 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.55%) lower than cumulative innermost loop coverage (75.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 (10.61 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 43.48% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.70 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (76.02%)

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 5912.91% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.25% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (75.42%)

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.46%)

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 (18.90%). 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.60%) lower than cumulative innermost loop coverage (75.42%)

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 (10.42 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 37.50% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.87 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (75.62%)

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 6651.32% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.34% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (74.96%)

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.43%)

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 (20.51%). 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.67%) lower than cumulative innermost loop coverage (74.96%)

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 (10.48 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 37.14% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.89 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (73.60%)

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 7363.59% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 96.97% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (72.88%)

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.43%)

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 (19.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 (0.72%) lower than cumulative innermost loop coverage (72.88%)

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 (10.45 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 32.61% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 2.02 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (73.33%)

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 8106.03% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 97.02% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (72.54%)

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.44%)

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 (22.00%). 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 (72.54%)

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 (10.63 s)

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

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

Functions without compilation information (typically not compiled with -g and -grecord-gcc-switches) cumulate 37.21% of the time spent in analyzed modules. Check that -g and (-grecord-gcc-switches or -frecord-command-line) are present. Remark: if -g and (-grecord-gcc-switches / -frecord-command-line) are 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.

[ 3 / 3 ] Optimization level option is correctly used

[ 2 / 3 ] Security settings from the host restrict profiling. Some metrics will be missing or incomplete.

Current value for kernel.perf_event_paranoid is 2. If possible, set it to 1 or check with your system administrator which flag can be used to achieve this.

[ 1.88 / 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 ( -mcpu=native ).

[ 2 / 2 ] Application is correctly profiled ("Others" category represents 0.00 % 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.

[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (71.73%)

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 8826.29% of observed threads are actually active

[ 4 / 4 ] CPU activity is good

CPU cores are active 96.75% of time

[ 4 / 4 ] Loop profile is not flat

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

[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (70.98%)

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.44%)

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 (17.51%). 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.75%) lower than cumulative innermost loop coverage (70.98%)

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)