	*************************************************
	*                                               *
	*          ONE-View report generation           *
	*                                               *
	*************************************************

[MAQAO] Info: Experiment configuration summary is available adding -dbg=1 in command line

* [MAQAO] Warning: Experiment directory /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/run/oneview_runs/defaults/gcc/oneview_results_1790771388 already exists and is reused.
           It can be replaced using --replace in the command line.
[MAQAO] Info: 
[MAQAO] Info: START THE APPLICATION PROFILING
[MAQAO] Info: -> RUNNING THE PROFILER...
[MAQAO] Info:   LPROF has already been run
[MAQAO] Info: STOP THE APPLICATION PROFILING
[MAQAO] Info: 
[MAQAO] Info: START FUNCTIONS AND LOOPS ANALYSIS ...
[MAQAO] Info: STOP FUNCTIONS AND LOOPS ANALYSIS ...
[MAQAO] Info: 
[MAQAO] Info: START THE REPORT GENERATION
[MAQAO] Info: -> ONE-VIEW EXPERIMENT DIRECTORY: /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/run/oneview_runs/defaults/gcc/oneview_results_1790771388


+====================================================================================================================+
+                                                    1  -  GLOBAL                                                    +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                             1.1  -  Experiment Summary                                             +
+--------------------------------------------------------------------------------------------------------------------+

  Application:			/beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/run/base_runs/defaults/gcc/exec
  Timestamp:			2026-09-30 14:29:48
  Universal Timestamp:		1790771388
  Experiment Type:		MPI; OpenMP; Throughput; 
  Machine:			ins01.benchmarkcenter.megware.com
  Architecture:			x86_64
  Micro Architecture:		ZEN_V4
  Model Name:			AMD EPYC 9654 96-Core Processor
  Cache Size:			1024 KB
  Number of Cores:		96
  OS Version:			Linux 5.14.0-687.29.1.el9_8.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 23 16:18:48 EDT 2026
  Compilation Options:		
		exec: GNU C89 11.5.0 20240719 (Red Hat 11.5.0-14) -march=znver4 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw -mavx512dq -mavx512cd -mno-avx512er -mno-avx512pf -mavx512vbmi -mavx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mavx512vpopcntdq -mavx512vbmi2 -mgfni -mvpclmulqdq -mavx512vnni -mavx512bitalg -mavx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mpku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=1024 -mtune=znver4 -g -O3 -std=gnu90 -fno-omit-frame-pointer -fcf-protection=none -fopenmp -funroll-loops 
  Number of processes observed:	8
  Number of threads observed:	192
  MAQAO version:		2026.1.0
  MAQAO build:			6d1be1d51c1e63266254997eb301734a7264775d::20260810-150026




+--------------------------------------------------------------------------------------------------------------------+
+                                               1.2  -  Global Metrics                                               +
+--------------------------------------------------------------------------------------------------------------------+

  Total Time:				78.41 s
  Max (Thread Active Time):		77.83 s
  Average Active Time:			70.33 s
  Activity Ratio:			90.0 %
  Average number of active threads:	172.225
  Affinity Stability:			99.8 %
  Time spent in analyzed loops:		92.5 %
  Time spent in analyzed innermost loops: 44.5 %
  Time spent in user code:		92.7 %
  Compilation Options Score:		100
  Array Access Efficiency:		72.5 %

   Potential Speedups
  ----------------------------------------------------
  Perfect Flow Complexity:		1.02
  Perfect OpenMP/MPI/Pthread/TBB:	1.01
  Perfect OpenMP/MPI/Pthread/TBB + Load Distribution:	1.14
  If No Scalar Integer:
      Potential Speedup:		1.17
      Nb Loops to get 80%:		11
  If FP Vectorized:
      Potential Speedup:		1.64
      Nb Loops to get 80%:		6
  If Fully Vectorized:
      Potential Speedup:		3.49
      Nb Loops to get 80%:		27
  If Only FP Arithmetic:
      Potential Speedup:		1.72
      Nb Loops to get 80%:		11




+--------------------------------------------------------------------------------------------------------------------+
+                                             1.3  -  Potential Speedups                                             +
+--------------------------------------------------------------------------------------------------------------------+

  If No Scalar Integer:
      Number of loops   | 1      | 10     | 20     | 29     | 40     | 
      Cumulated Speedup | 1.0705 | 1.1355 | 1.1565 | 1.1656 | 1.1687 | 
  Top 5 loops:
    exec - 2072:	1.0705
    exec - 3016:	1.0896
    exec - 3025:	1.105
    exec - 3012:	1.1104
    exec - 2414:	1.1154

  If FP Vectorized:
      Number of loops   | 1      | 10     | 20     | 29     | 40     | 
      Cumulated Speedup | 1.1881 | 1.6138 | 1.6399 | 1.6430 | 1.6430 | 
  Top 5 loops:
    exec - 2072:	1.1881
    exec - 2074:	1.325
    exec - 3016:	1.3917
    exec - 3025:	1.4594
    exec - 3017:	1.5127

  If Fully Vectorized:
      Number of loops   | 1      | 10     | 20     | 29     | 40     | 
      Cumulated Speedup | 1.2909 | 2.4437 | 2.8306 | 3.0674 | 3.2486 | 
  Top 5 loops:
    exec - 2072:	1.2909
    exec - 2074:	1.5975
    exec - 3016:	1.7437
    exec - 3025:	1.9007
    exec - 3017:	2.0628

  If Only FP Arithmetic:
      Number of loops   | 1      | 10     | 20     | 29     | 40     | 
      Cumulated Speedup | 1.2673 | 1.5697 | 1.6331 | 1.6656 | 1.6895 | 
  Top 5 loops:
    exec - 2072:	1.2673
    exec - 3016:	1.3514
    exec - 3025:	1.4375
    exec - 2071:	1.4751
    exec - 3012:	1.5048



+====================================================================================================================+
+                                                   2  -  SUMMARY                                                    +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                             2.1  -  EXPERIMENT QUALITY                                             +
+--------------------------------------------------------------------------------------------------------------------+

  [4 / 4] Application profile is long enough (77.83 s)
To have good quality measurements, it is advised that the application profiling time is greater than 10 seconds.

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

  [3 / 3] Most of time spent in analyzed modules comes from functions with compilation options informations and
-fno-omit-frame-pointer is present
-fno-omit-frame-pointer improves the accuracy of callchains found during the application profiling.

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


  [2.9985520489068 / 3] Most of time spent in analyzed modules (99.95%) comes from functions compiled with architecture specialization option
-march=znver4


  [3 / 3] Optimization level option is correctly 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.


+--------------------------------------------------------------------------------------------------------------------+
+                                                2.2  -  CODE QUALITY                                                +
+--------------------------------------------------------------------------------------------------------------------+

  [4 / 4] Enough time of the experiment time spent in analyzed loops (92.54%)
If the time spent in analyzed loops is less than 30%, standard loop optimizations will have a limited impact on
application performances.

  [3 / 4] A significant amount of threads are idle (10.30%)
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.

  [3 / 4] CPU activity is below 90% (89.96%)
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% (27.35%), representing an hotspot for the application

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

  [0 / 3] Cumulative Outermost/In between loops coverage (48.03%) greater than cumulative innermost loop coverage (44.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)



+--------------------------------------------------------------------------------------------------------------------+
+                                               2.3  -  LOOPS OVERVIEW                                               +
+--------------------------------------------------------------------------------------------------------------------+

  Top 5 loops:
   + exec - 2072:
     analysis: Execution Time: 27 % - Vectorization Ratio: 23.30 % - Vector Length Use: 19.78 %
     Loop Computation Issues: 6
        [4] [SA] Presence of expensive FP instructions - Perform hoisting, change algorithm, use SVML or proper
            numerical library or perform value profiling (count the number of distinct input values). There are 1
            issues (= instructions) costing 4 points each.
        [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.
     Control Flow Issues: 1002
        [1000] [SA] Too many paths (2049 paths) - Simplify control structure. There are 2049 issues ( = paths) costing 1
            point, limited to 1000.
        [2] [SA] Non innermost loop (Outermost) - Collapse loop with innermost ones. This issue costs 2 points.
     Data Access Issues: 42
        [24] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 6 issues (=
            instructions) costing 4 points each.
        [18] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 18 issues (= instructions) costing 1 point each.
     Vectorization Roadblocks: 1002
        [1000] [SA] Too many paths (2049 paths) - Simplify control structure. There are 2049 issues ( = paths) costing 1
            point, limited to 1000.
        [2] [SA] Non innermost loop (Outermost) - Collapse loop with innermost ones. This issue costs 2 points.
     Inefficient Vectorization: 42
        [24] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 6 issues (=
            instructions) costing 4 points each.
        [18] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 18 issues (= instructions) costing 1 point each.

   + exec - 2074:
     analysis: Execution Time: 19 % - Vectorization Ratio: 40.00 % - Vector Length Use: 25.00 %
     Loop Computation Issues: 4
        [4] [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.
     Data Access Issues: 32
        [4] [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost.
            There are 1 issues ( = indirect data accesses) costing 4 point each.
        [16] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 4 issues (=
            instructions) costing 4 points each.
        [12] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 12 issues (= instructions) costing 1 point each.
     Vectorization Roadblocks: 4
        [4] [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost.
            There are 1 issues ( = indirect data accesses) costing 4 point each.
     Inefficient Vectorization: 28
        [16] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 4 issues (=
            instructions) costing 4 points each.
        [12] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 12 issues (= instructions) costing 1 point each.

   + exec - 3016:
     analysis: Execution Time: 6 % - Vectorization Ratio: 26.09 % - Vector Length Use: 20.65 %
     Loop Computation Issues: 2
        [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.
     Control Flow Issues: 38
        [36] [SA] Too many paths (32 paths) - Simplify control structure. There are 32 issues ( = paths) costing 1
            point each with a malus of 4 points.
        [2] [SA] Non innermost loop (Outermost) - Collapse loop with innermost ones. This issue costs 2 points.
     Data Access Issues: 21
        [12] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 3 issues (=
            instructions) costing 4 points each.
        [9] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 9 issues (= instructions) costing 1 point each.
     Vectorization Roadblocks: 38
        [36] [SA] Too many paths (32 paths) - Simplify control structure. There are 32 issues ( = paths) costing 1
            point each with a malus of 4 points.
        [2] [SA] Non innermost loop (Outermost) - Collapse loop with innermost ones. This issue costs 2 points.
     Inefficient Vectorization: 21
        [12] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 3 issues (=
            instructions) costing 4 points each.
        [9] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 9 issues (= instructions) costing 1 point each.

   + exec - 3025:
     analysis: Execution Time: 5 % - Vectorization Ratio: 25.53 % - Vector Length Use: 20.48 %
     Loop Computation Issues: 2
        [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.
     Control Flow Issues: 2
        [2] [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points.
     Data Access Issues: 21
        [12] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 3 issues (=
            instructions) costing 4 points each.
        [9] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 9 issues (= instructions) costing 1 point each.
     Vectorization Roadblocks: 1002
        [1000] [SA] Too many paths (at least 1000 paths) - Simplify control structure. There are at least 1000 issues ( =
            paths) costing 1 point.
        [2] [SA] Non innermost loop (InBetween) - Collapse loop with innermost ones. This issue costs 2 points.
     Inefficient Vectorization: 21
        [12] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 3 issues (=
            instructions) costing 4 points each.
        [9] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 9 issues (= instructions) costing 1 point each.

   + exec - 3017:
     analysis: Execution Time: 5 % - Vectorization Ratio: 40.00 % - Vector Length Use: 25.00 %
     Loop Computation Issues: 4
        [4] [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.
     Data Access Issues: 32
        [4] [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost.
            There are 1 issues ( = indirect data accesses) costing 4 point each.
        [16] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 4 issues (=
            instructions) costing 4 points each.
        [12] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 12 issues (= instructions) costing 1 point each.
     Vectorization Roadblocks: 4
        [4] [SA] Presence of indirect accesses - Use array restructuring or gather instructions to lower the cost.
            There are 1 issues ( = indirect data accesses) costing 4 point each.
     Inefficient Vectorization: 28
        [16] [SA] Presence of expensive instructions (GATHER/SCATTER) - Use array restructuring. There are 4 issues (=
            instructions) costing 4 points each.
        [12] [SA] Presence of special instructions executing on a single port (INSERT/EXTRACT, BLEND/MERGE) - Simplify
            data access and try to get stride 1 access. There are 12 issues (= instructions) costing 1 point each.



+====================================================================================================================+
+                                                 3  -  APPLICATION                                                  +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                               3.1  -  Categorization                                               +
+--------------------------------------------------------------------------------------------------------------------+

   Category | IO     | Exe    | System  | Others  | Memory | String | MPI   | TBB   | OMP   | Pthread | Math  |
  ----------+--------+--------+---------+---------+--------+--------+-------+-------+-------+---------+-------+
   Time (%) | 0.00   | 92.71  | 4.26    | 0.00    | 0.00   | 0.34   | 0.05  | 0.00  | 2.64  | 0.00    | 0.00  |




+--------------------------------------------------------------------------------------------------------------------+
+                                          3.2  -  Function Based Profiling                                          +
+--------------------------------------------------------------------------------------------------------------------+

   Buckets                    | Nb Functions              | Coverage                  | Cumulated Coverage        |
  ----------------------------+---------------------------+---------------------------+---------------------------+
   > 8%                       | 2                         | 70.58                     | 70.58                     |
   4% to 8%                   | 1                         | 4.26                      | 74.84                     |
   2% to 4%                   | 2                         | 4.81                      | 79.65                     |
   1% to 2%                   | 8                         | 10.98                     | 90.63                     |
   0.5% to 1%                 | 6                         | 4.71                      | 95.34                     |
   0.25% to 0.5%              | 11                        | 3.77                      | 99.10                     |
   0.125% to 0.25%            | 2                         | 0.38                      | 99.48                     |
   < 0.125%                   | 54                        | 0.47                      | 99.95                     |




+--------------------------------------------------------------------------------------------------------------------+
+                                            3.3  -  Loop Based Profiling                                            +
+--------------------------------------------------------------------------------------------------------------------+

   Buckets                    | Nb Loops                  | Coverage                  | Cumulated Coverage        |
  ----------------------------+---------------------------+---------------------------+---------------------------+
   > 8%                       | 1                         | 19.34                     | 19.34                     |
   4% to 8%                   | 2                         | 10.10                     | 29.44                     |
   2% to 4%                   | 1                         | 2.18                      | 31.62                     |
   1% to 2%                   | 1                         | 1.56                      | 33.18                     |
   0.5% to 1%                 | 6                         | 4.38                      | 37.56                     |
   0.25% to 0.5%              | 14                        | 5.05                      | 42.61                     |
   0.125% to 0.25%            | 4                         | 0.64                      | 43.25                     |
   < 0.125%                   | 85                        | 1.26                      | 44.51                     |


+====================================================================================================================+
+                                                  4  -  FUNCTIONS                                                   +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                              4.1  -  Top 10 Functions                                              +
+--------------------------------------------------------------------------------------------------------------------+

   Function                                               | Module              | Coverage (%)   | Time (s)       |
  --------------------------------------------------------+---------------------+----------------+----------------+
   hypre_ParCSRRelaxThreads._omp_fn.1                     | exec                | 46.70          | 32.85          |
   hypre_CSRMatrixMatvecOutOfPlace._omp_fn.6              | exec                | 23.88          | 16.79          |
   unknown_kernel_region                                  | kernel              | 4.26           | 3.00           |
   omp_get_num_procs                                      | libgomp.so.1.0.0    | 2.63           | 1.85           |
   hypre_ParCSRRelaxThreads._omp_fn.0                     | exec                | 2.18           | 1.54           |
   hypre_BoomerAMGCreate2ndS._omp_fn.7                    | exec                | 1.65           | 1.16           |
   hypre_SeqVectorAxpy._omp_fn.0                          | exec                | 1.56           | 1.10           |
   hypre_BoomerAMGBuildMultipass._omp_fn.5                | exec                | 1.54           | 1.08           |
   hypre_BoomerAMGBuildMultipass._omp_fn.10               | exec                | 1.44           | 1.01           |
   hypre_BoomerAMGCreateS._omp_fn.1                       | exec                | 1.24           | 0.87           |


+====================================================================================================================+
+                                                    5  -  LOOPS                                                     +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                                5.1  -  Top 10 Loops                                                +
+--------------------------------------------------------------------------------------------------------------------+

   Loop Id        | Module              | Source Location                                        | Coverage (%)   |
  ----------------+---------------------+--------------------------------------------------------+----------------+
   2072           | exec                | ams.c:3669-3682                                        | 27.35          |
   2074           | exec                | ams.c:3672-3675                                        | 19.34          |
   3016           | exec                | csr_matvec.c:307-314                                   | 6.34           |
   3025           | exec                | csr_matvec.c:256-263                                   | 5.71           |
   3017           | exec                | csr_matvec.c:310-312                                   | 5.38           |
   3026           | exec                | csr_matvec.c:259-261                                   | 4.72           |
   2071           | exec                | ams.c:3659-3659                                        | 2.18           |
   3012           | exec                | csr_matvec.c:334-341                                   | 1.73           |
   3065           | exec                | vector.c:452-452                                       | 1.56           |
   3033           | exec                | csr_matvec.c:564-564,csr_matvec.c:567-567              | 1.11           |





+====================================================================================================================+
+                                                     6  -  CQA                                                      +
+====================================================================================================================+


+--------------------------------------------------------------------------------------------------------------------+
+                                                   6.1  -  Loops                                                    +
+--------------------------------------------------------------------------------------------------------------------+





      6.1.1  -  Loop 2072 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/parcsr_ls/ams.c:3669-3682.

Warnings:
 - Non-innermost loop: analyzing only self part (ignoring child loops).
 - Ignoring paths for analysis
 - Too many paths. If you really need to analyze all of the 2049 paths individually, rerun with max-paths=2049
 - RecMII not computed since number of paths is unknown or > max_paths
 - Streams not analyzed since number of paths is unknown or > max_paths

Try to simplify control and/or increase the maximum number of paths per function/loop through the 'max-paths-nb' option.

This loop has 2049 execution paths.

The presence of multiple execution paths is typically the main/first bottleneck.
Try to simplify control inside loop: ideally, try to remove all conditional expressions, for example by (if applicable):
 - hoisting them (moving them outside the loop)
 - turning them into conditional moves, MIN or MAX


Ex: if (x<0) x=0 => x = (x<0 ? 0 : x) (or MAX(0,x) after defining the corresponding macro)


      6.1.1.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

4% of peak computational performance is used (1.15 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.1.1.1  -  Code clean check
  ----------------------------------------------------------------------------------------------------------

Detected a slowdown caused by scalar integer instructions (typically used for address computation).
By removing them, you can lower the cost of an iteration from 54.67 to 41.50 cycles (1.32x speedup).

Workaround
 - Try to reorganize arrays of structures to structures of arrays
 - Consider to permute loops (see vectorization gain report)



      6.1.1.1.2  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 19% of vector register length is used (average across all SSE/AVX instructions).


Details
23% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 51% of SSE/AVX loads are used in vector version.
 - 0% of SSE/AVX stores are used in vector version.
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 85% of SSE/AVX multiply instructions are used in vector version.
 - 0% of SSE/AVX fused multiply-add instructions are used in vector version.
 - 0% of SSE/AVX divide and square root instructions are used in vector version.
 - 24% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.1.1.3  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.1.1.4  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.1.1.5  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 6 FMA (fused multiply-add) operations.
Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
Estimated speedup by perfect pairing: 1.00x.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.1.1.6  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 6 occurrences<<list_path_1_complex_1>>
 - VUCOMISD: 1 occurrences<<list_path_1_complex_2>>



      6.1.1.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses). By removing them, you can lower the cost of an iteration from 54.67 to 31.67 cycles (1.73x speedup).

Details
 - VGATHERQPD: 6 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.1.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

34 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
6 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.1.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 63 FP arithmetical operations:
 - 31: addition or subtraction (6 inside FMA instructions)
 - 31: multiply (6 inside FMA instructions)
 - 1: divide
The binary loop is loading 800 bytes (100 double precision FP elements).
The binary loop is storing 8 bytes (1 double precision FP elements).


      6.1.1.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.2  -  Loop 2074 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/parcsr_ls/ams.c:3672-3675.

The related source loop is not unrolled or unrolled with no peel/tail loop.

      6.1.2.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

2% of peak computational performance is used (0.52 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.2.1.1  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 25% of vector register length is used (average across all SSE/AVX instructions).


Details
40% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 50% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.2.1.2  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.2.1.3  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.2.1.4  -  FMA
  ----------------------------------------------------------------------------------------------------------

Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.2.1.5  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 4 occurrences<<list_path_1_complex_1>>



      6.1.2.1.6  -  Slow data structures access
  ----------------------------------------------------------------------------------------------------------

Detected data structures (typically arrays) that cannot be efficiently read/written

Details
 - Irregular (variable stride) or indirect: 1 occurrence(s)
Non-unit stride (uncontiguous) accesses are not efficiently using data caches


Workaround
Try to remove indirect accesses. If applicable, precompute elements out of the innermost loop.


      6.1.2.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses).

Details
 - VGATHERQPD: 4 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.2.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

16 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
4 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.2.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 32 FP arithmetical operations:
 - 16: addition or subtraction
 - 16: multiply
The binary loop is loading 384 bytes (48 double precision FP elements).


      6.1.2.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.3  -  Loop 3016 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:307-314.

Warnings:
 - Non-innermost loop: analyzing only self part (ignoring child loops).
 - Ignoring paths for analysis
 - Too many paths. Rerun with max-paths=32
 - RecMII not computed since number of paths is unknown or > max_paths
 - Streams not analyzed since number of paths is unknown or > max_paths

Try to simplify control and/or increase the maximum number of paths per function/loop through the 'max-paths-nb' option.

This loop has 32 execution paths.

The presence of multiple execution paths is typically the main/first bottleneck.
Try to simplify control inside loop: ideally, try to remove all conditional expressions, for example by (if applicable):
 - hoisting them (moving them outside the loop)
 - turning them into conditional moves, MIN or MAX


Ex: if (x<0) x=0 => x = (x<0 ? 0 : x) (or MAX(0,x) after defining the corresponding macro)


      6.1.3.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

4% of peak computational performance is used (1.13 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.3.1.1  -  Code clean check
  ----------------------------------------------------------------------------------------------------------

Detected a slowdown caused by scalar integer instructions (typically used for address computation).
By removing them, you can lower the cost of an iteration from 26.50 to 19.67 cycles (1.35x speedup).

Workaround
 - Try to reorganize arrays of structures to structures of arrays
 - Consider to permute loops (see vectorization gain report)



      6.1.3.1.2  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 20% of vector register length is used (average across all SSE/AVX instructions).


Details
26% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 56% of SSE/AVX loads are used in vector version.
 - 0% of SSE/AVX stores are used in vector version.
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 0% of SSE/AVX fused multiply-add instructions are used in vector version.
 - 30% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.3.1.3  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.3.1.4  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.3.1.5  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 3 FMA (fused multiply-add) operations.
Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.3.1.6  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 3 occurrences<<list_path_1_complex_1>>



      6.1.3.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses). By removing them, you can lower the cost of an iteration from 26.50 to 15.00 cycles (1.77x speedup).

Details
 - VGATHERQPD: 3 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.3.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

15 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
3 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.3.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 30 FP arithmetical operations:
 - 15: addition or subtraction (3 inside FMA instructions)
 - 15: multiply (3 inside FMA instructions)
The binary loop is loading 400 bytes (50 double precision FP elements).
The binary loop is storing 8 bytes (1 double precision FP elements).


      6.1.3.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.07 FP operations per loaded or stored byte.







      6.1.4  -  Loop 3025 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:256-263.

Warnings:
 - Non-innermost loop: analyzing only self part (ignoring child loops).
 - Ignoring paths for analysis
 - Failed to get the number of paths
 - RecMII not computed since number of paths is unknown or > max_paths
 - Streams not analyzed since number of paths is unknown or > max_paths


      6.1.4.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

4% of peak computational performance is used (1.12 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.4.1.1  -  Code clean check
  ----------------------------------------------------------------------------------------------------------

Detected a slowdown caused by scalar integer instructions (typically used for address computation).
By removing them, you can lower the cost of an iteration from 26.83 to 20.83 cycles (1.29x speedup).

Workaround
 - Try to reorganize arrays of structures to structures of arrays
 - Consider to permute loops (see vectorization gain report)



      6.1.4.1.2  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 20% of vector register length is used (average across all SSE/AVX instructions).


Details
25% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 60% of SSE/AVX loads are used in vector version.
 - 0% of SSE/AVX stores are used in vector version.
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 0% of SSE/AVX fused multiply-add instructions are used in vector version.
 - 27% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.4.1.3  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.4.1.4  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.4.1.5  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 3 FMA (fused multiply-add) operations.
Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.4.1.6  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 3 occurrences<<list_path_1_complex_1>>



      6.1.4.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses). By removing them, you can lower the cost of an iteration from 26.83 to 15.33 cycles (1.75x speedup).

Details
 - VGATHERQPD: 3 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.4.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

15 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
3 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.4.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 30 FP arithmetical operations:
 - 15: addition or subtraction (3 inside FMA instructions)
 - 15: multiply (3 inside FMA instructions)
The binary loop is loading 384 bytes (48 double precision FP elements).
The binary loop is storing 8 bytes (1 double precision FP elements).


      6.1.4.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.5  -  Loop 3017 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:310-312.

The related source loop is not unrolled or unrolled with no peel/tail loop.

      6.1.5.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

2% of peak computational performance is used (0.50 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.5.1.1  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 25% of vector register length is used (average across all SSE/AVX instructions).


Details
40% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 50% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.5.1.2  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.5.1.3  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.5.1.4  -  FMA
  ----------------------------------------------------------------------------------------------------------

Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.5.1.5  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 4 occurrences<<list_path_1_complex_1>>



      6.1.5.1.6  -  Slow data structures access
  ----------------------------------------------------------------------------------------------------------

Detected data structures (typically arrays) that cannot be efficiently read/written

Details
 - Irregular (variable stride) or indirect: 1 occurrence(s)
Non-unit stride (uncontiguous) accesses are not efficiently using data caches


Workaround
Try to remove indirect accesses. If applicable, precompute elements out of the innermost loop.


      6.1.5.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses).

Details
 - VGATHERQPD: 4 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.5.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

16 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
4 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.5.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 32 FP arithmetical operations:
 - 16: addition or subtraction
 - 16: multiply
The binary loop is loading 384 bytes (48 double precision FP elements).


      6.1.5.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.6  -  Loop 3026 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:259-261.

The related source loop is not unrolled or unrolled with no peel/tail loop.

      6.1.6.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

2% of peak computational performance is used (0.52 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.6.1.1  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 25% of vector register length is used (average across all SSE/AVX instructions).


Details
40% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 50% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.6.1.2  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.6.1.3  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.6.1.4  -  FMA
  ----------------------------------------------------------------------------------------------------------

Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.6.1.5  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 4 occurrences<<list_path_1_complex_1>>



      6.1.6.1.6  -  Slow data structures access
  ----------------------------------------------------------------------------------------------------------

Detected data structures (typically arrays) that cannot be efficiently read/written

Details
 - Irregular (variable stride) or indirect: 1 occurrence(s)
Non-unit stride (uncontiguous) accesses are not efficiently using data caches


Workaround
Try to remove indirect accesses. If applicable, precompute elements out of the innermost loop.


      6.1.6.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses).

Details
 - VGATHERQPD: 4 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.6.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

16 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
4 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.6.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 32 FP arithmetical operations:
 - 16: addition or subtraction
 - 16: multiply
The binary loop is loading 384 bytes (48 double precision FP elements).


      6.1.6.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.7  -  Loop 2071 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/parcsr_ls/ams.c:3659.

It is main loop of related source loop which is unrolled by 4 (including vectorization).

      6.1.7.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

0% of peak computational performance is used (0.00 out of 48.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.7.1.1  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is vectorized, but using only 256 out of 512 bits (AVX/AVX2 instructions on AVX-512 processors).


Details
All SSE/AVX instructions are used in vector version (process two or more data elements in vector registers).


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.7.1.2  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Performance is limited by:
 - reading data from caches/RAM (load units are a bottleneck)
 - writing data to caches/RAM (the store unit is a bottleneck)

By removing all these bottlenecks, you can lower the cost of an iteration from 5.33 to 4.00 cycles (1.33x speedup).


Workaround
 - Read less array elements
 - Write less array elements
 - Provide more information to your compiler:
  * hardcode the bounds of the corresponding 'for' loop
  * use the 'restrict' C99 keyword





      6.1.7.1.3  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512




      6.1.7.1.4  -  Vector unaligned load/store instructions
  ----------------------------------------------------------------------------------------------------------

Detected 16 optimal vector unaligned load/store instructions.


Details
 - VMOVUPD: 16 occurrences<<list_path_1_vec_align_1>>


Workaround
Use vector aligned instructions:
 1) align your arrays on 64 bytes boundaries: replace { void *p = malloc (size); } with { void *p; posix_memalign (&p, 64, size); }.
 2) inform your compiler that your arrays are vector aligned: if array 'foo' is 64 bytes-aligned, define a pointer 'p_foo' as __builtin_assume_aligned (foo, 64) and use it instead of 'foo' in the loop.
<<image_vec_align>>


      6.1.7.1.5  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

No instructions are processing arithmetic or math operations on FP elements. This loop is probably writing/copying data or processing integer elements.


      6.1.7.1.6  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop does not contain any FP arithmetical operations.
The binary loop is loading 256 bytes.
The binary loop is storing 256 bytes.







      6.1.8  -  Loop 3012 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:334-341.

Warnings:
 - Non-innermost loop: analyzing only self part (ignoring child loops).
 - Ignoring paths for analysis
 - Too many paths. Rerun with max-paths=32
 - RecMII not computed since number of paths is unknown or > max_paths
 - Streams not analyzed since number of paths is unknown or > max_paths

Try to simplify control and/or increase the maximum number of paths per function/loop through the 'max-paths-nb' option.

This loop has 32 execution paths.

The presence of multiple execution paths is typically the main/first bottleneck.
Try to simplify control inside loop: ideally, try to remove all conditional expressions, for example by (if applicable):
 - hoisting them (moving them outside the loop)
 - turning them into conditional moves, MIN or MAX


Ex: if (x<0) x=0 => x = (x<0 ? 0 : x) (or MAX(0,x) after defining the corresponding macro)


      6.1.8.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

4% of peak computational performance is used (1.13 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.8.1.1  -  Code clean check
  ----------------------------------------------------------------------------------------------------------

Detected a slowdown caused by scalar integer instructions (typically used for address computation).
By removing them, you can lower the cost of an iteration from 26.50 to 19.67 cycles (1.35x speedup).

Workaround
 - Try to reorganize arrays of structures to structures of arrays
 - Consider to permute loops (see vectorization gain report)



      6.1.8.1.2  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is poorly vectorized.
Only 20% of vector register length is used (average across all SSE/AVX instructions).


Details
26% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):
 - 56% of SSE/AVX loads are used in vector version.
 - 0% of SSE/AVX stores are used in vector version.
 - 0% of SSE/AVX addition or subtraction instructions are used in vector version.
 - 0% of SSE/AVX fused multiply-add instructions are used in vector version.
 - 30% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.8.1.3  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.8.1.4  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.8.1.5  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 3 FMA (fused multiply-add) operations.
Presence of both ADD/SUB and MUL operations.

Workaround
Try to change order in which elements are evaluated (using parentheses) in arithmetic expressions containing both ADD/SUB and MUL operations to enable your compiler to generate FMA instructions wherever possible.
For instance a + b*c is a valid FMA (MUL then ADD).
However (a+b)* c cannot be translated into an FMA (ADD then MUL).




      6.1.8.1.6  -  Complex instructions
  ----------------------------------------------------------------------------------------------------------

Detected COMPLEX INSTRUCTIONS.


Details
These instructions generate more than one micro-operation and only one of them can be decoded during a cycle and the extra micro-operations increase pressure on execution units.
 - VGATHERQPD: 3 occurrences<<list_path_1_complex_1>>



      6.1.8.1.7  -  Gather/scatter instructions
  ----------------------------------------------------------------------------------------------------------

Detected gather/scatter instructions (typically caused by indirect accesses). By removing them, you can lower the cost of an iteration from 26.50 to 15.00 cycles (1.77x speedup).

Details
 - VGATHERQPD: 3 occurrences<<list_path_1_gather_scatter_1>>


Workaround
Try to simplify your code and/or replace indirect accesses with unit-stride ones.


      6.1.8.1.8  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

15 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).
3 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.8.1.9  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 30 FP arithmetical operations:
 - 15: addition or subtraction (3 inside FMA instructions)
 - 15: multiply (3 inside FMA instructions)
The binary loop is loading 400 bytes (50 double precision FP elements).
The binary loop is storing 8 bytes (1 double precision FP elements).


      6.1.8.1.10  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.07 FP operations per loaded or stored byte.







      6.1.9  -  Loop 3065 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/vector.c:452.

It is main loop of related source loop which is unrolled by 4 (including vectorization).

      6.1.9.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

33% of peak computational performance is used (8.00 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.9.1.1  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is vectorized, but using only 256 out of 512 bits (AVX/AVX2 instructions on AVX-512 processors).
<<image_4x64_512>>

Details
All SSE/AVX instructions are used in vector version (process two or more data elements in vector registers).


Workaround
Read the "512-bits vectorization" report at "Potential" confidence level.


      6.1.9.1.2  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Performance is limited by:
 - reading data from caches/RAM (load units are a bottleneck)
 - writing data to caches/RAM (the store unit is a bottleneck)

By removing all these bottlenecks, you can lower the cost of an iteration from 8.00 to 4.33 cycles (1.85x speedup).


Workaround
 - Read less array elements
 - Write less array elements
 - Provide more information to your compiler:
  * hardcode the bounds of the corresponding 'for' loop
  * use the 'restrict' C99 keyword





      6.1.9.1.3  -  512-bits vectorization
  ----------------------------------------------------------------------------------------------------------

On some x86 processors supporting 512-bits vectorization, compilers are often too conservative and limit vectorization to 256 bits. Performance can then be improved by enforcing 512-bits vectorization, especially with many vectorized and high trip count loops. 512-bits vectorization performance overhead (compared to 256-bits) is generally lower on newer processors.


Workaround
Recompile with -mprefer-vector-width=512


      6.1.9.1.4  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 32 FMA (fused multiply-add) operations.




      6.1.9.1.5  -  Vector unaligned load/store instructions
  ----------------------------------------------------------------------------------------------------------

Detected 16 optimal vector unaligned load/store instructions.


Details
 - VMOVUPD: 16 occurrences<<list_path_1_vec_align_1>>


Workaround
Use vector aligned instructions:
 1) align your arrays on 64 bytes boundaries: replace { void *p = malloc (size); } with { void *p; posix_memalign (&p, 64, size); }.
 2) inform your compiler that your arrays are vector aligned: if array 'foo' is 64 bytes-aligned, define a pointer 'p_foo' as __builtin_assume_aligned (foo, 64) and use it instead of 'foo' in the loop.
<<image_vec_align>>


      6.1.9.1.6  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

8 AVX instructions are processing arithmetic or math operations on double precision FP elements in vector mode (four at a time).



      6.1.9.1.7  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 64 FP arithmetical operations:
 - 32: addition or subtraction (all inside FMA instructions)
 - 32: multiply (all inside FMA instructions)
The binary loop is loading 512 bytes (64 double precision FP elements).
The binary loop is storing 256 bytes (32 double precision FP elements).


      6.1.9.1.8  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.08 FP operations per loaded or stored byte.







      6.1.10  -  Loop 3033 from exec
  ==========================================================================================================

The loop is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:564-567.

Analyzed code is defined in /beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/build/AMG/AMG/seq_mv/csr_matvec.c:564,567.

Warnings:
 - Non-innermost loop: analyzing only self part (ignoring child loops).
 - Ignoring paths for analysis
 - Too many paths. Rerun with max-paths=16
 - RecMII not computed since number of paths is unknown or > max_paths
 - Streams not analyzed since number of paths is unknown or > max_paths

Try to simplify control and/or increase the maximum number of paths per function/loop through the 'max-paths-nb' option.

This loop has 16 execution paths.

The presence of multiple execution paths is typically the main/first bottleneck.
Try to simplify control inside loop: ideally, try to remove all conditional expressions, for example by (if applicable):
 - hoisting them (moving them outside the loop)
 - turning them into conditional moves, MIN or MAX


Ex: if (x<0) x=0 => x = (x<0 ? 0 : x) (or MAX(0,x) after defining the corresponding macro)


      6.1.10.1  -  Path 1
  ----------------------------------------------------------------------------------------------------------

4% of peak computational performance is used (1.04 out of 24.00 FLOP per cycle (GFLOPS @ 1GHz))

      6.1.10.1.1  -  Code clean check
  ----------------------------------------------------------------------------------------------------------

Detected a slowdown caused by scalar integer instructions (typically used for address computation).
By removing them, you can lower the cost of an iteration from 13.50 to 9.33 cycles (1.45x speedup).

Workaround
 - Try to reorganize arrays of structures to structures of arrays
 - Consider to permute loops (see vectorization gain report)



      6.1.10.1.2  -  Vectorization
  ----------------------------------------------------------------------------------------------------------

Your loop is not vectorized.
8 data elements could be processed at once in vector registers.
<<image_1x64_512>>By vectorizing your loop, you can lower the cost of an iteration from 13.50 to 2.79 cycles (4.84x speedup).

Details
All SSE/AVX instructions are used in scalar version (process only one data element in vector registers).
Since your execution units are vector units, only a vectorized loop can use their full power.


Workaround
 - Try another compiler or update/tune your current one:
  * recompile with fassociative-math (included in Ofast or ffast-math) to extend loop vectorization to FP reductions.
 - Remove inter-iterations dependences from your loop and make it unit-stride:
  * If your arrays have 2 or more dimensions, check whether elements are accessed contiguously and, otherwise, try to permute loops accordingly:
C storage order is row-major: for(i) for(j) a[j][i] = b[j][i]; (slow, non stride 1) => for(i) for(j) a[i][j] = b[i][j]; (fast, stride 1)<<image_row_maj>>
  * If your loop streams arrays of structures (AoS), try to use structures of arrays instead (SoA):
for(i) a[i].x = b[i].x; (slow, non stride 1) => for(i) a.x[i] = b.x[i]; (fast, stride 1)



      6.1.10.1.3  -  Execution units bottlenecks
  ----------------------------------------------------------------------------------------------------------

Found no such bottlenecks but see expert reports for more complex bottlenecks.




      6.1.10.1.4  -  FMA
  ----------------------------------------------------------------------------------------------------------

Detected 7 FMA (fused multiply-add) operations.




      6.1.10.1.5  -  Type of elements and instruction set
  ----------------------------------------------------------------------------------------------------------

7 SSE or AVX instructions are processing arithmetic or math operations on double precision FP elements in scalar mode (one at a time).



      6.1.10.1.6  -  Matching between your loop (in the source code) and the binary loop
  ----------------------------------------------------------------------------------------------------------

The binary loop is composed of 14 FP arithmetical operations:
 - 7: addition or subtraction (all inside FMA instructions)
 - 7: multiply (all inside FMA instructions)
The binary loop is loading 240 bytes (30 double precision FP elements).
The binary loop is storing 56 bytes (7 double precision FP elements).


      6.1.10.1.7  -  Arithmetic intensity
  ----------------------------------------------------------------------------------------------------------

Arithmetic intensity is 0.05 FP operations per loaded or stored byte.





[MAQAO] Info: STOP THE REPORT GENERATION
[MAQAO] Info: 
[MAQAO] Info: If your application produces files, they can be found in directory "/beegfs/hackathon/users/eoseret/qaas_runs_test/179-077-0265/intel/AMG/run/oneview_runs/defaults/gcc/oneview_run_1790771388"
[MAQAO] Info: 
