orig_default | aocc_default | gcc_default | icx_10 | aocc_5 | gcc_3 |
---|---|---|---|---|---|
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. | [ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. | [ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. | [ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. | [ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. | [ 3 / 3 ] Host configuration allows retrieval of all necessary metrics. |
Not available for this run | [ 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 / 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. | Not available for this run | Not available for this run | Not available for this run |
Not available for this run | [ 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 / 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. Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ). | [ 0 / 3 ] Compilation of some functions is not optimized for the target processor Application run on the GRANITE_RAPIDS micro-architecture while the code was specialized for GRANITERAPIDS. Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ). | [ 0 / 3 ] Compilation of some functions is not optimized for the target processor Application run on the GRANITE_RAPIDS micro-architecture while the code was specialized for graniterapids. Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ). | [ 0 / 3 ] Compilation of some functions is not optimized for the target processor Application run on the GRANITE_RAPIDS micro-architecture while the code was specialized for graniterapids. Architecture specific options are needed to produce efficient code for a specific processor ( -x(target) or -ax(target) ). |
Not available for this run | [ 2.09 / 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 30.43% of the time spent in analyzed modules. Check that -g and -grecord-gcc-switches are present. Remark: if -g and -grecord-gcc-switches 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. | [ 2.38 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information Functions without compilation information (typically not compiled with -g) cumulate 20.69% 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.03 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information Functions without compilation information (typically not compiled with -g) cumulate 98.99% 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. | [ 1.78 / 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.74% of the time spent in analyzed modules. Check that -g and -grecord-gcc-switches are present. Remark: if -g and -grecord-gcc-switches 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. | [ 2.38 / 3 ] Most of time spent in analyzed modules comes from functions without compilation information Functions without compilation information (typically not compiled with -g) cumulate 20.69% 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. |
[ 4 / 4 ] Application profile is long enough (16.38 s) To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds. | [ 4 / 4 ] Application profile is long enough (14.68 s) To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds. | [ 0 / 4 ] Application profile is too short (7.50 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. | [ 4 / 4 ] Application profile is long enough (14.75 s) To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds. | [ 4 / 4 ] Application profile is long enough (14.68 s) To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds. | [ 0 / 4 ] Application profile is too short (7.75 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. |
[ 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 | [ 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 | [ 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 | [ 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 | [ 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 | [ 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 |
[ 0 / 9 ] Compilation options are not available Compilation options are an important optimization leverage but ONE-View is not able to analyze them. | [ 3 / 3 ] Optimization level option is correctly used | [ 3 / 3 ] Optimization level option is correctly used | [ 3 / 3 ] Optimization level option is correctly used | [ 3 / 3 ] Optimization level option is correctly used | [ 3 / 3 ] Optimization level option is correctly used |
[ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. | [ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. | [ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. | [ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. | [ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. | [ 1 / 1 ] Lstopo present. The Topology lstopo report will be generated. |
orig_default | aocc_default | gcc_default | icx_10 | aocc_5 | gcc_3 |
---|---|---|---|---|---|
[ 4 / 4 ] CPU activity is good CPU cores are active 95.30% of time | [ 4 / 4 ] CPU activity is good CPU cores are active 94.91% of time | [ 0 / 4 ] CPU activity is below 90% (4.42%) 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 ] CPU activity is good CPU cores are active 95.11% of time | [ 4 / 4 ] CPU activity is good CPU cores are active 94.88% of time | [ 0 / 4 ] CPU activity is below 90% (4.51%) 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 ] Affinity is good (98.41%) Threads are not migrating to CPU cores: probably successfully pinned | [ 4 / 4 ] Affinity is good (98.20%) Threads are not migrating to CPU cores: probably successfully pinned | [ 3 / 4 ] Affinity stability is lower than 90% (80.55%) 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. | [ 4 / 4 ] Affinity is good (98.30%) Threads are not migrating to CPU cores: probably successfully pinned | [ 4 / 4 ] Affinity is good (98.24%) Threads are not migrating to CPU cores: probably successfully pinned | [ 3 / 4 ] Affinity stability is lower than 90% (79.87%) 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. |
[ 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 (14.37%). 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 | [ 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.58%). 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 ] Functions mostly use all threads Functions running on a reduced number of threads (typically sequential code) cover less than 10% of application walltime (8.79%) | [ 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 (16.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 | [ 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.86%). 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 ] Functions mostly use all threads Functions running on a reduced number of threads (typically sequential code) cover less than 10% of application walltime (8.96%) |
[ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.16%) lower than cumulative innermost loop coverage (8.44%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex | [ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.13%) lower than cumulative innermost loop coverage (3.22%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex | [ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.12%) lower than cumulative innermost loop coverage (5.18%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex | [ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.19%) lower than cumulative innermost loop coverage (1.88%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex | [ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.12%) lower than cumulative innermost loop coverage (3.34%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex | [ 3 / 3 ] Cumulative Outermost/In between loops coverage (0.10%) lower than cumulative innermost loop coverage (4.38%) Having cumulative Outermost/In between loops coverage greater than cumulative innermost loop coverage will make loop optimization more complex |
[ 1 / 4 ] A significant amount of threads are idle (51.99%) 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. | [ 1 / 4 ] A significant amount of threads are idle (54.00%) 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. | [ 0 / 4 ] A significant amount of threads are idle (96.10%) 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. | [ 1 / 4 ] A significant amount of threads are idle (55.05%) 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. | [ 1 / 4 ] A significant amount of threads are idle (51.90%) 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. | [ 0 / 4 ] A significant amount of threads are idle (96.02%) 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 / 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 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 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 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 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 BLAS2 operations BLAS2 calls usually could make a poor cache usage and could benefit from inlining. |
[ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (8.44%) 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. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (3.22%) 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. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (5.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. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (1.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. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (3.34%) 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. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed innermost loops (4.38%) 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.00%) is spend in BLAS1 operations It could be more efficient to inline by hand BLAS1 operations | [ 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 ] Less than 10% (0.00%) is spend in BLAS1 operations It could be more efficient to inline by hand BLAS1 operations | [ 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 ] Less than 10% (0.00%) is spend in BLAS1 operations It could be more efficient to inline by hand BLAS1 operations | [ 3 / 3 ] Less than 10% (0.00%) is spend in BLAS1 operations It could be more efficient to inline by hand BLAS1 operations |
[ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions) | [ 2 / 2 ] Less than 10% (0.32%) is spend in Libm/SVML (special functions) | [ 2 / 2 ] Less than 10% (0.46%) is spend in Libm/SVML (special functions) | [ 2 / 2 ] Less than 10% (0.00%) is spend in Libm/SVML (special functions) | [ 2 / 2 ] Less than 10% (0.17%) is spend in Libm/SVML (special functions) | [ 2 / 2 ] Less than 10% (0.47%) is spend in Libm/SVML (special functions) |
[ 4 / 4 ] Loop profile is not flat At least one loop coverage is greater than 4% (6.92%), representing an hotspot for the application | [ 0 / 4 ] Loop profile is flat No hotspot found in the application (greatest loop coverage is 1.42%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (3.30%) | [ 0 / 4 ] Loop profile is flat No hotspot found in the application (greatest loop coverage is 1.58%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (5.09%) | [ 0 / 4 ] Loop profile is flat No hotspot found in the application (greatest loop coverage is 0.48%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (2.00%) | [ 0 / 4 ] Loop profile is flat No hotspot found in the application (greatest loop coverage is 1.65%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (3.41%) | [ 0 / 4 ] Loop profile is flat No hotspot found in the application (greatest loop coverage is 1.19%), and the twenty hottest loops cumulated coverage is lower than 20% of the application profiled time (4.30%) |
[ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (8.60%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (3.36%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (5.30%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (2.07%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (3.47%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. | [ 0 / 4 ] Too little time of the experiment time spent in analyzed loops (4.48%) If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on application performances. |
Analysis | r0 | r1 | r2 | r3 | r4 | r5 | |
---|---|---|---|---|---|---|---|
Loop Computation Issues | Presence of expensive FP instructions | 1 | 2 | 2 | 2 | 2 | 2 |
Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA | 5 | 5 | 3 | 3 | 3 | 4 | |
Presence of a large number of scalar integer instructions | 1 | 2 | 2 | 1 | 2 | 1 | |
Low iteration count | 0 | 0 | 0 | 0 | 0 | 1 | |
Control Flow Issues | Presence of calls | 1 | 2 | 4 | 3 | 2 | 3 |
Presence of 2 to 4 paths | 2 | 4 | 1 | 3 | 4 | 1 | |
Presence of more than 4 paths | 0 | 1 | 1 | 1 | 1 | 1 | |
Non-innermost loop | 1 | 1 | 0 | 1 | 1 | 0 | |
Low iteration count | 0 | 0 | 0 | 0 | 0 | 1 | |
Data Access Issues | Presence of constant non-unit stride data access | 1 | 3 | 3 | 2 | 3 | 2 |
Presence of indirect access | 0 | 0 | 1 | 0 | 0 | 1 | |
More than 10% of the vector loads instructions are unaligned | 0 | 1 | 2 | 0 | 1 | 4 | |
Presence of special instructions executing on a single port | 2 | 3 | 2 | 2 | 3 | 2 | |
More than 20% of the loads are accessing the stack | 3 | 4 | 4 | 4 | 4 | 3 | |
Vectorization Roadblocks | Presence of calls | 1 | 2 | 4 | 3 | 2 | 3 |
Presence of 2 to 4 paths | 2 | 4 | 1 | 3 | 4 | 1 | |
Presence of more than 4 paths | 1 | 1 | 1 | 1 | 1 | 1 | |
Non-innermost loop | 1 | 1 | 0 | 1 | 1 | 0 | |
Presence of constant non-unit stride data access | 1 | 3 | 3 | 2 | 3 | 2 | |
Presence of indirect access | 0 | 0 | 1 | 0 | 0 | 1 | |
Out of user code | 1 | 0 | 0 | 1 | 0 | 0 | |
Inefficient Vectorization | Presence of special instructions executing on a single port | 2 | 3 | 2 | 2 | 3 | 2 |
Use of masked instructions | 0 | 1 | 1 | 1 | 2 | 1 |