OV - exec - Function hypre

/home/eoseret/qaas_runs_GNR/173-927-0874/intel/AMG/build/AMG/AMG/utilities/binsearch.c: 33 - 53

--------------------------------------------------------------------------------

33:    low = 0;

34:    high = list_length-1;

35:    while (not_found && low <= high)

36:    {

37:       m = (low + high) / 2;

38:       if (value < list[m])

39:       {

40:          high = m - 1;

41:       }

42:       else if (value > list[m])

43:       {

44:         low = m + 1;

[...]

52:    return -1;

53: }

0x5508c0 DEC	%RDX

0x5508c3 JS	55092e

0x5508c5 XOR	%R8D,%R8D

0x5508c8 JMP	550909

0x5508ca NOPW	%CS:(%RAX,%RAX,1)

0x5508d5 NOPW	%CS:(%RAX,%RAX,1)

0x5508e0 NOPW	%CS:(%RAX,%RAX,1)

0x5508eb NOPW	%CS:(%RAX,%RAX,1)

0x5508f6 NOPW	%CS:(%RAX,%RAX,1)

(3009) 0x550900 LEA	-0x1(%RAX),%RDX

(3009) 0x550904 CMP	%R8,%RDX

(3009) 0x550907 JL	55092e

(3009) 0x550909 LEA	(%R8,%RDX,1),%RCX

(3009) 0x55090d MOV	%RCX,%RAX

(3009) 0x550910 SHR	$0x3f,%RAX

(3009) 0x550914 ADD	%RCX,%RAX

(3009) 0x550917 SAR	$0x1,%RAX

(3009) 0x55091a MOV	%RAX,%R9

(3009) 0x55091d CMP	%RSI,(%RDI,%RAX,8)

(3009) 0x550921 JG	550900

(3009) 0x550923 JGE	550935

(3009) 0x550925 LEA	0x1(%RAX),%R8

(3009) 0x550929 CMP	%R8,%RDX

(3009) 0x55092c JGE	550909

0x55092e MOV	$-0x1,%R9

0x550935 MOV	%R9,%RAX

0x550938 RET

0x550939 NOPL	(%RAX)

Coverage (%)	Name	Source Location	Module
○94.23	gomp_thread_start	team.c:130	libgomp.so.1.0.0
►3.54+	hypre_BoomerAMGSetup	par_amg_setup.c:1227	exec
○	hypre_PCGSetup	pcg.c:234	exec
○	main	amg.c:398	exec
○	__libc_start_call_main		libc.so.6
►1.68+	hypre_BoomerAMGSetup	par_amg_setup.c:737	exec
○	hypre_PCGSetup	pcg.c:234	exec
○	main	amg.c:398	exec
○	__libc_start_call_main		libc.so.6

Path /

Average path: Display a virtual path defined by average values of all real paths

The code analyzed by CQA in that panel excludes loops and represents 0.00% of application time for run gcc_5

Source file and lines	binsearch.c:33-53
Module	exec

The function is defined in /home/eoseret/qaas_runs_GNR/173-927-0874/intel/AMG/build/AMG/AMG/utilities/binsearch.c:33-44,52-53.

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is not vectorized. 16 data elements could be processed at once in vector registers. By vectorizing your function, you can lower the cost of an iteration from 2.17 to 0.14 cycles (16.00x 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 function can use their full power.

Workaround

Try another compiler or update/tune your current one
Make array accesses unit-stride:
- If your function 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)

Execution units bottlenecks

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

No data for this section

Type of elements and instruction set

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

Matching between your function (in the source code) and the binary function

The binary function does not contain any FP arithmetical operations. The binary function does not load or store any data.

General properties

nb instructions	13
nb uops	13
loop length	82
used x86 registers	4
used mmx registers	0
used xmm registers	0
used ymm registers	0
used zmm registers	0
nb stack references	0

Front-end

MACRO FUSION NOT POSSIBLE FIT IN UOP CACHE

micro-operation queue	2.17 cycles
front end	2.17 cycles

Back-end

	P0	P1	P2	P3	P4	P5	P6	P7	P8	P9	P10	P11
uops	1.00	0.40	0.33	0.33	0.00	0.40	1.00	0.00	0.00	0.00	0.20	0.33
cycles	1.00	0.40	0.33	0.33	0.00	0.40	1.00	0.00	0.00	0.00	0.20	0.33

Execution ports to units layout:

P0 (256 bits): VPU, BRU, ALU, DIV/SQRT
P1 (256 bits): ALU, VPU
P2 (512 bits): load
P3 (512 bits): load
P4 (512 bits): store data
P5 (512 bits): ALU, VPU
P6: ALU, BRU
P7: store address
P8: store address
P9 (512 bits): store data
P10: ALU
P11 (512 bits): load

Cycles executing div or sqrt instructions

NA

Cycles summary

Front-end	2.17
Dispatch	1.00
Overall L1	2.17

Vectorization ratios

all	0%
load	NA (no load vectorizable/vectorized instructions)
store	NA (no store vectorizable/vectorized instructions)
mul	NA (no mul vectorizable/vectorized instructions)
add-sub	NA (no add-sub vectorizable/vectorized instructions)
fma	NA (no fma vectorizable/vectorized instructions)
div/sqrt	NA (no div/sqrt vectorizable/vectorized instructions)
other	0%

Vector efficiency ratios

all	6%
load	NA (no load vectorizable/vectorized instructions)
store	NA (no store vectorizable/vectorized instructions)
mul	NA (no mul vectorizable/vectorized instructions)
add-sub	NA (no add-sub vectorizable/vectorized instructions)
fma	NA (no fma vectorizable/vectorized instructions)
div/sqrt	NA (no div/sqrt vectorizable/vectorized instructions)
other	6%

Cycles and memory resources usage

Assuming all data fit into the L1 cache, each call to the function takes 2.17 cycles.

Front-end bottlenecks

Performance is limited by instruction throughput (loading/decoding program instructions to execution core) (front-end is a bottleneck). By removing all these bottlenecks, you can lower the cost of an iteration from 2.17 to 1.00 cycles (2.17x speedup).

ASM code

In the binary file, the address of the function is: 5508c0

Instruction	Nb FU	P0	P1	P2	P3	P5	P6	P10	P11	Latency	Recip. throughput	Vectorization
DEC %RDX	1	0	0	0	0	0	0	0	0	1	0.17	N/A
JS 55092e <hypre_BinarySearch+0x6e>	1	0.50	0	0	0	0	0.50	0	0	0	0.50	N/A
XOR %R8D,%R8D	1	0	0	0	0	0	0	0	0	0	0.17	scal (6.3%)
JMP 550909 <hypre_BinarySearch+0x49>	1	0	0	0	0	0	0	0	0	0	5.84	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
MOV $-0x1,%R9	1	0.20	0.20	0	0	0.20	0.20	0.20	0	1	0.20	scal (6.3%)
MOV %R9,%RAX	1	0	0	0	0	0	0	0	0	1	0.17	N/A
RET	1	0.50	0	0.33	0.33	0	0.50	0	0.33	0	2.13	N/A
NOPL (%RAX)	1	0	0	0	0	0	0	0	0	0	0.17	N/A

The code analyzed by CQA in that panel excludes loops and represents 0.00% of application time for run gcc_5

Source file and lines	binsearch.c:33-53
Module	exec

The function is defined in /home/eoseret/qaas_runs_GNR/173-927-0874/intel/AMG/build/AMG/AMG/utilities/binsearch.c:33-44,52-53.

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is not vectorized. 16 data elements could be processed at once in vector registers. By vectorizing your function, you can lower the cost of an iteration from 2.17 to 0.14 cycles (16.00x 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 function can use their full power.

Workaround

Try another compiler or update/tune your current one
Make array accesses unit-stride:
- If your function 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)

Execution units bottlenecks

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

No data for this section

Type of elements and instruction set

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

Matching between your function (in the source code) and the binary function

The binary function does not contain any FP arithmetical operations. The binary function does not load or store any data.

General properties

nb instructions	13
nb uops	13
loop length	82
used x86 registers	4
used mmx registers	0
used xmm registers	0
used ymm registers	0
used zmm registers	0
nb stack references	0

Front-end

MACRO FUSION NOT POSSIBLE FIT IN UOP CACHE

micro-operation queue	2.17 cycles
front end	2.17 cycles

Back-end

	P0	P1	P2	P3	P4	P5	P6	P7	P8	P9	P10	P11
uops	1.00	0.40	0.33	0.33	0.00	0.40	1.00	0.00	0.00	0.00	0.20	0.33
cycles	1.00	0.40	0.33	0.33	0.00	0.40	1.00	0.00	0.00	0.00	0.20	0.33

Execution ports to units layout:

P0 (256 bits): VPU, BRU, ALU, DIV/SQRT
P1 (256 bits): ALU, VPU
P2 (512 bits): load
P3 (512 bits): load
P4 (512 bits): store data
P5 (512 bits): ALU, VPU
P6: ALU, BRU
P7: store address
P8: store address
P9 (512 bits): store data
P10: ALU
P11 (512 bits): load

Cycles executing div or sqrt instructions

NA

Cycles summary

Front-end	2.17
Dispatch	1.00
Overall L1	2.17

Vectorization ratios

all	0%
load	NA (no load vectorizable/vectorized instructions)
store	NA (no store vectorizable/vectorized instructions)
mul	NA (no mul vectorizable/vectorized instructions)
add-sub	NA (no add-sub vectorizable/vectorized instructions)
fma	NA (no fma vectorizable/vectorized instructions)
div/sqrt	NA (no div/sqrt vectorizable/vectorized instructions)
other	0%

Vector efficiency ratios

all	6%
load	NA (no load vectorizable/vectorized instructions)
store	NA (no store vectorizable/vectorized instructions)
mul	NA (no mul vectorizable/vectorized instructions)
add-sub	NA (no add-sub vectorizable/vectorized instructions)
fma	NA (no fma vectorizable/vectorized instructions)
div/sqrt	NA (no div/sqrt vectorizable/vectorized instructions)
other	6%

Cycles and memory resources usage

Assuming all data fit into the L1 cache, each call to the function takes 2.17 cycles.

Front-end bottlenecks

Performance is limited by instruction throughput (loading/decoding program instructions to execution core) (front-end is a bottleneck). By removing all these bottlenecks, you can lower the cost of an iteration from 2.17 to 1.00 cycles (2.17x speedup).

ASM code

In the binary file, the address of the function is: 5508c0

Instruction	Nb FU	P0	P1	P2	P3	P5	P6	P10	P11	Latency	Recip. throughput	Vectorization
DEC %RDX	1	0	0	0	0	0	0	0	0	1	0.17	N/A
JS 55092e <hypre_BinarySearch+0x6e>	1	0.50	0	0	0	0	0.50	0	0	0	0.50	N/A
XOR %R8D,%R8D	1	0	0	0	0	0	0	0	0	0	0.17	scal (6.3%)
JMP 550909 <hypre_BinarySearch+0x49>	1	0	0	0	0	0	0	0	0	0	5.84	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
NOPW %CS:(%RAX,%RAX,1)	1	0	0	0	0	0	0	0	0	0	0.17	N/A
MOV $-0x1,%R9	1	0.20	0.20	0	0	0.20	0.20	0.20	0	1	0.20	scal (6.3%)
MOV %R9,%RAX	1	0	0	0	0	0	0	0	0	1	0.17	N/A
RET	1	0.50	0	0.33	0.33	0	0.50	0	0.33	0	2.13	N/A
NOPL (%RAX)	1	0	0	0	0	0	0	0	0	0	0.17	N/A

Name	Coverage (%)	Time (s)
▼hypre_BinarySearch–	0.03	0.01
○Loop 3009 - binsearch.c:35-44 - exec	0.03	0.01

Report Configuration

Vectorization

Details

Workaround

Execution units bottlenecks

Type of elements and instruction set

Matching between your function (in the source code) and the binary function

General properties

Front-end

Back-end

Cycles summary

Vectorization ratios

Vector efficiency ratios

Cycles and memory resources usage

Front-end bottlenecks

ASM code

Vectorization

Details

Workaround

Execution units bottlenecks

Type of elements and instruction set

Matching between your function (in the source code) and the binary function

General properties

Front-end

Back-end

Cycles summary

Vectorization ratios

Vector efficiency ratios

Cycles and memory resources usage

Front-end bottlenecks

ASM code