[ 0 / 4 ] Application profile is too short (0.08 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.

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

[ 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 0.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 ] 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" (43.75 %)

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)

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

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

[ 4 / 4 ] Loop profile is not flat

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

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

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 / 3 ] Less than 10% (0%) is spend in BLAS1 operations

It could be more efficient to inline by hand BLAS1 operations

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

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%) is spend in Libm/SVML (special functions)

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

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