[ 0 / 4 ] Application profile is too short (6.25 s)

If the overall application profiling time is less than 10 seconds, many of the measurements at function or loop level will very likely be under the measurement quality threshold (0,1 seconds).
Rerun to increase runtime duration: for example use a larger dataset or include a repetition loop.

[ 3 / 3 ] Most of time spent in analyzed modules comes from functions with source/debug info

-g option gives access to debugging informations, such are source locations.

[ 2.40 / 3 ] Most of time spent in analyzed modules comes from functions with compilation options informations but -fno-omit-frame-pointer is missing

-fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.

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

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

-march=x86-64 option is used but it is not specific enough to produce efficient code.

[ 3 / 3 ] Optimization level option is correctly used

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

[ 0 / 0 ] Fastmath not used

Consider to add ffast-math to compilation flags (or replace -O3 with -Ofast) to unlock potential extra speedup by relaxing floating-point computation consistency. Warning: floating-point accuracy may be reduced and the compliance to IEEE/ISO rules/specifications for math functions will be relaxed, typically 'errno' will no longer be set after calling some math functions.

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

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

[ 4 / 4 ] CPU activity is good

CPU cores are active 99.07% of time

[ 4 / 4 ] Loop profile is not flat

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

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

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

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

[ 3 / 3 ] Functions mostly use all threads

Functions running on a reduced number of threads (typically sequential code) cover less than 10% of the application profiled time (1.60%)

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

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)