Help is available by moving the cursor above any symbol or by checking MAQAO website.
[ 4 / 4 ] Application profile is long enough (211.53 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improve the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (100.00%)
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.86% of observed threads are actually active
[ 4 / 4 ] CPU activity is good
CPU cores are active 99.86% of time
[ 4 / 4 ] Loop profile is not flat
At least one loop coverage is greater than 4% (86.94%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (91.20%)
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.98%)
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
[ 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 (0.00%)
[ 3 / 3 ] Cumulative Outermost/In between loops coverage (8.80%) lower than cumulative innermost loop coverage (91.20%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (110.30 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improve the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (100.00%)
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 191.27% of observed threads are actually active
[ 4 / 4 ] CPU activity is good
CPU cores are active 95.64% of time
[ 4 / 4 ] Loop profile is not flat
At least one loop coverage is greater than 4% (86.67%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (90.93%)
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.80%)
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
[ 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.14%)
[ 3 / 3 ] Cumulative Outermost/In between loops coverage (9.07%) lower than cumulative innermost loop coverage (90.93%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 9 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (59.71 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (100.00%)
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 353.92% of observed threads are actually active
[ 3 / 4 ] CPU activity is below 90% (88.49%)
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% (87.06%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (91.31%)
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.05%). 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 (8.68%) lower than cumulative innermost loop coverage (91.31%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 87 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (34.42 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (99.98%)
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 614.97% of observed threads are actually active
[ 3 / 4 ] CPU activity is below 90% (76.88%)
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% (86.90%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (91.15%)
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 (98.98%)
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 (26.18%). 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 (8.84%) lower than cumulative innermost loop coverage (91.15%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (21.85 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (99.94%)
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 976.26% of observed threads are actually active
[ 2 / 4 ] CPU activity is below 90% (61.04%)
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% (86.59%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (90.80%)
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 (98.27%)
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 (41.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 (9.14%) lower than cumulative innermost loop coverage (90.80%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 9 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (15.44 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (99.91%)
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 1379.82% of observed threads are actually active
[ 1 / 4 ] CPU activity is below 90% (43.14%)
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% (87.02%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (91.23%)
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 (97.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 (58.32%). 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 (8.68%) lower than cumulative innermost loop coverage (91.23%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 87 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (13.31 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improve the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (99.84%)
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 1599.69% of observed threads are actually active
[ 1 / 4 ] CPU activity is below 90% (33.35%)
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% (86.82%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (91.03%)
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 (97.02%)
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 (67.69%). 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 (8.81%) lower than cumulative innermost loop coverage (91.03%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
[ 4 / 4 ] Application profile is long enough (12.27 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.
[ 3 / 3 ] Optimization level option is correctly used
[ 3 / 3 ] Most of time spent in analyzed modules comes from functions compiled with -g and -fno-omit-frame-pointer
-g option gives access to debugging informations, such are source locations. -fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.
[ 3 / 3 ] Host configuration allows retrieval of all necessary metrics.
[ 3 / 3 ] Architecture specific option -mcpu is used
[ 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.
[ 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.
[ 4 / 4 ] Enough time of the experiment time spent in analyzed loops (99.78%)
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 1740.15% of observed threads are actually active
[ 0 / 4 ] CPU activity is below 90% (27.22%)
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% (86.76%), representing an hotspot for the application
[ 4 / 4 ] Enough time of the experiment time spent in analyzed innermost loops (90.97%)
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 (96.74%)
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 (73.46%). 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 (8.81%) lower than cumulative innermost loop coverage (90.97%)
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)
Loop ID | Analysis | Penalty Score |
---|---|---|
○Loop 4 - kmeans-gcc-O3-vectorize-soa | Execution Time: 86 % - Vectorization Ratio: 0.00 % - Vector Length Use: 23.61 % | |
►Loop 5 - kmeans-gcc-O3-vectorize-soa | Execution Time: 8 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.43 % | |
►Loop Computation Issues | 2 | |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Control Flow Issues | 2 | |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Data Access Issues | 4 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
►Vectorization Roadblocks | 6 | |
○ | [SA] Presence of constant non unit stride data access - Use array restructuring, perform loop interchange or use gather instructions to lower a bit the cost. There are 2 issues ( = data accesses) costing 2 point each. | 4 |
○ | [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points. | 2 |
►Loop 11 - kmeans-gcc-O3-vectorize-soa | Execution Time: 4 % - Vectorization Ratio: 0.00 % - Vector Length Use: 21.59 % | |
►Loop Computation Issues | 6 | |
○ | [SA] Less than 10% of the FP ADD/SUB/MUL arithmetic operations are performed using FMA - Reorganize arithmetic expressions to exhibit potential for FMA. This issue costs 4 points. | 4 |
○ | [SA] Presence of a large number of scalar integer instructions - Simplify loop structure, perform loop splitting or perform unroll and jam. This issue costs 2 points. | 2 |
►Data Access Issues | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |
►Vectorization Roadblocks | 12 | |
○ | [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost. There are 3 issues ( = indirect data accesses) costing 4 point each. | 12 |