OV - - Function _ZN6Kripke12ParallelComm12testRecievesEv

/beegfs/hackathon/users/eoseret/qaas_runs/170-850-6313/intel/Kripke/build/Kripke/src/Kripke/ParallelComm.cpp: 214 - 251

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

214: void ParallelComm::testRecieves(void){

215: #ifdef KRIPKE_USE_MPI

216:   // Check for any recv requests that have completed

217:   int num_requests = recv_requests.size();

218:   bool done = false;

219:   while(!done && num_requests > 0){

220:     // Create array of status variables

221:     std::vector<MPI_Status> recv_status(num_requests);

222:

223:     // Ask if either one or none of the recvs have completed?

224:     int index; // this will be the index of request that completed

225:     int complete_flag; // this is set to TRUE if somthing completed

226:     MPI_Testany(num_requests, &recv_requests[0], &index, &complete_flag, &recv_status[0]);

227:

228:     if(complete_flag != 0){

229:

230:       // get subdomain that this completed for

231:       int sdom_id = recv_subdomains[index];

232:

233:       // remove the request from the list

234:       recv_requests.erase(recv_requests.begin()+index);

235:       recv_subdomains.erase(recv_subdomains.begin()+index);

236:       num_requests --;

237:

238:       // decrement the dependency count for that subdomain

239:       for(size_t i = 0;i < queue_sdom_ids.size();++ i){

240:         if(queue_sdom_ids[i] == sdom_id){

241:           queue_depends[i] --;

[...]

251: }

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_construct.h: 119 - 119

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

119:       ::new((void*)__p) _Tp(std::forward<_Args>(__args)...);

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ext/new_allocator.h: 127 - 145

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

127: 	return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));

[...]

145: 	::operator delete(__p

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_vector.h: 919 - 1046

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

919:       { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }

[...]

1046: 	return *(this->_M_impl._M_start + __n);

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_algobase.h: 429 - 1115

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

429: 	  const ptrdiff_t _Num = __last - __first;

430: 	  if (_Num)

431: 	    __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);

[...]

911:       for (; __first != __last; ++__first)

912: 	*__first = __value;

[...]

1115:       if (__n <= 0)

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_iterator.h: 1028 - 1182

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

1028:       : _M_current(__i) { }

[...]

1091:       { return __normal_iterator(_M_current + __n); }

[...]

1182:     { return __lhs.base() != __rhs.base(); }

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/vector.tcc: 174 - 176

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

174:       if (__position + 1 != end())

175: 	_GLIBCXX_MOVE3(__position + 1, end(), __position);

176:       --this->_M_impl._M_finish;

0x9eaa0 PUSH	%RBP

0x9eaa1 MOV	%RSP,%RBP

0x9eaa4 PUSH	%R15

0x9eaa6 PUSH	%R14

0x9eaa8 PUSH	%R13

0x9eaaa PUSH	%R12

0x9eaac PUSH	%RBX

0x9eaad PUSH	%RAX

0x9eaae MOV	0x30(%RDI),%R14

0x9eab2 SUB	0x28(%RDI),%R14

0x9eab6 SHR	$0x2,%R14

0x9eaba TEST	%R14D,%R14D

0x9eabd JLE	9ec11

0x9eac3 MOV	%RDI,%RBX

0x9eac6 XOR	%R12D,%R12D

0x9eac9 NOPL	(%RAX)

(1356) 0x9ead0 MOV	%R14D,%EAX

(1356) 0x9ead3 SAL	$0x2,%RAX

(1356) 0x9ead7 LEA	(%RAX,%RAX,4),%R15

(1356) 0x9eadb MOV	%R15,%RDI

(1356) 0x9eade CALL	a8c30 <@plt_start@+0x160>

(1356) 0x9eae3 VXORPS	%XMM0,%XMM0,%XMM0

(1356) 0x9eae7 MOV	%RAX,%R13

(1356) 0x9eaea MOVL	$0,0x10(%RAX)

(1356) 0x9eaf1 VMOVUPS	%XMM0,(%RAX)

(1356) 0x9eaf5 CMP	$0x1,%R14D

(1356) 0x9eaf9 JE	9eb1f

(1356) 0x9eafb MOV	$0x14,%EAX

  (1358) 0x9eb00 MOV	0x10(%R13),%ECX

  (1358) 0x9eb04 MOV	%ECX,0x10(%R13,%RAX,1)

  (1358) 0x9eb09 VMOVUPS	(%R13),%XMM0

  (1358) 0x9eb0f VMOVUPS	%XMM0,(%R13,%RAX,1)

  (1358) 0x9eb16 ADD	$0x14,%RAX

  (1358) 0x9eb1a CMP	%RAX,%R15

  (1358) 0x9eb1d JNE	9eb00

(1356) 0x9eb1f MOV	0x28(%RBX),%RSI

(1356) 0x9eb23 LEA	-0x2c(%RBP),%RDX

(1356) 0x9eb27 LEA	-0x30(%RBP),%RCX

(1356) 0x9eb2b MOV	%R14D,%EDI

(1356) 0x9eb2e MOV	%R13,%R8

(1356) 0x9eb31 CALL	a9040 <@plt_start@+0x570>

(1356) 0x9eb36 CMPL	$0,-0x30(%RBP)

(1356) 0x9eb3a JE	9ebe0

(1356) 0x9eb40 MOVSXD	-0x2c(%RBP),%RAX

(1356) 0x9eb44 MOV	0x40(%RBX),%RCX

(1356) 0x9eb48 MOV	0x28(%RBX),%RDI

(1356) 0x9eb4c MOV	0x30(%RBX),%RDX

(1356) 0x9eb50 MOV	(%RCX,%RAX,4),%R15D

(1356) 0x9eb54 LEA	0x4(%RDI,%RAX,4),%RSI

(1356) 0x9eb59 CMP	%RDX,%RSI

(1356) 0x9eb5c JE	9eb76

(1356) 0x9eb5e LEA	(%RDI,%RAX,4),%RDI

(1356) 0x9eb62 SUB	%RSI,%RDX

(1356) 0x9eb65 CALL	a90f0 <@plt_start@+0x620>

(1356) 0x9eb6a MOV	0x30(%RBX),%RSI

(1356) 0x9eb6e MOV	0x40(%RBX),%RCX

(1356) 0x9eb72 MOVSXD	-0x2c(%RBP),%RAX

(1356) 0x9eb76 ADD	$-0x4,%RSI

(1356) 0x9eb7a MOV	%RSI,0x30(%RBX)

(1356) 0x9eb7e LEA	0x4(%RCX,%RAX,4),%RSI

(1356) 0x9eb83 MOV	0x48(%RBX),%RDX

(1356) 0x9eb87 CMP	%RDX,%RSI

(1356) 0x9eb8a JE	9eb9c

(1356) 0x9eb8c LEA	(%RCX,%RAX,4),%RDI

(1356) 0x9eb90 SUB	%RSI,%RDX

(1356) 0x9eb93 CALL	a90f0 <@plt_start@+0x620>

(1356) 0x9eb98 MOV	0x48(%RBX),%RSI

(1356) 0x9eb9c ADD	$-0x4,%RSI

(1356) 0x9eba0 DEC	%R14D

(1356) 0x9eba3 MOV	%RSI,0x48(%RBX)

(1356) 0x9eba7 MOV	0x58(%RBX),%RCX

(1356) 0x9ebab MOV	0x60(%RBX),%RSI

(1356) 0x9ebaf SUB	%RCX,%RSI

(1356) 0x9ebb2 JE	9ebe3

(1356) 0x9ebb4 SAR	$0x2,%RSI

(1356) 0x9ebb8 MOV	$0x1,%EAX

(1356) 0x9ebbd CMP	$0x2,%RSI

(1356) 0x9ebc1 CMOVB	%RAX,%RSI

(1356) 0x9ebc5 XOR	%EAX,%EAX

(1356) 0x9ebc7 NOPW	(%RAX,%RAX,1)

  (1357) 0x9ebd0 CMP	%R15D,(%RCX,%RAX,4)

  (1357) 0x9ebd4 JE	9ebfc

  (1357) 0x9ebd6 INC	%RAX

  (1357) 0x9ebd9 CMP	%RAX,%RSI

  (1357) 0x9ebdc JNE	9ebd0

(1356) 0x9ebde JMP	9ebe3

(1356) 0x9ebe0 MOV	$0x1,%R12B

(1356) 0x9ebe3 MOV	%R13,%RDI

(1356) 0x9ebe6 CALL	a8b10 <@plt_start@+0x40>

(1356) 0x9ebeb TEST	$0x1,%R12B

(1356) 0x9ebef JNE	9ec11

(1356) 0x9ebf1 TEST	%R14D,%R14D

(1356) 0x9ebf4 JG	9ead0

0x9ebfa JMP	9ec11

(1356) 0x9ebfc MOV	0x70(%RBX),%RCX

(1356) 0x9ec00 DECL	(%RCX,%RAX,4)

(1356) 0x9ec03 MOV	%R13,%RDI

(1356) 0x9ec06 CALL	a8b10 <@plt_start@+0x40>

(1356) 0x9ec0b TEST	$0x1,%R12B

(1356) 0x9ec0f JE	9ebf1

0x9ec11 ADD	$0x8,%RSP

0x9ec15 POP	%RBX

0x9ec16 POP	%R12

0x9ec18 POP	%R13

0x9ec1a POP	%R14

0x9ec1c POP	%R15

0x9ec1e POP	%RBP

0x9ec1f RET

0x9ec20 MOV	%R13,%RDI

0x9ec23 MOV	%RAX,%RBX

0x9ec26 CALL	a8b10 <@plt_start@+0x40>

0x9ec2b MOV	%RBX,%RDI

0x9ec2e CALL	a90e0 <@plt_start@+0x610>

0x9ec33 INT	$0x3

0x9ec34 INT	$0x3

0x9ec35 INT	$0x3

0x9ec36 INT	$0x3

0x9ec37 INT	$0x3

0x9ec38 INT	$0x3

0x9ec39 INT	$0x3

0x9ec3a INT	$0x3

0x9ec3b INT	$0x3

0x9ec3c INT	$0x3

0x9ec3d INT	$0x3

0x9ec3e INT	$0x3

0x9ec3f INT	$0x3

Path /

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

Source file and lines	ParallelComm.cpp:214-251
Module	libkripke.so

The function is defined in:

/beegfs/hackathon/users/eoseret/qaas_runs/170-850-6313/intel/Kripke/build/Kripke/src/Kripke/ParallelComm.cpp:214-241,251
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_construct.h:119
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ext/new_allocator.h:127,145
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_vector.h:919,1046
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_algobase.h:429-431,911-912,1115
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_iterator.h:1028,1091,1182
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/vector.tcc:174-176

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is not vectorized. Only 10% of vector register length is used (average across all SSE/AVX instructions). By vectorizing your function, you can lower the cost of an iteration from 5.17 to 0.35 cycles (14.96x 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

CALL instructions

Detected function call instructions.

Details

Calling (and then returning from) a function prevents many compiler optimizations (like vectorization), breaks control flow (which reduces pipeline performance) and executes extra instructions to save/restore the registers used inside it, which is very expensive (dozens of cycles). Consider to inline small functions.

unknown: 2 occurrences

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 is loading 16 bytes.

General properties

nb instructions	43
nb uops	31
loop length	97
used x86 registers	9
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	5.17 cycles
front end	5.17 cycles

Back-end

	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5
uops	2.50	1.50	1.25	1.25	2.50	1.33	1.33	1.33	0.00	0.00	0.00	0.00	0.00	0.00
cycles	2.50	1.50	1.25	1.25	2.50	1.33	1.33	1.33	0.00	0.00	0.00	0.00	0.00	0.00

Execution ports to units layout:

ALU0/BRU0: ALU
ALU1: ALU
ALU2: ALU
ALU3: ALU
BRU1:
AGU0 (256 bits): store address, load
AGU1 (256 bits): store address, load
AGU2 (256 bits): store address, load
FP0 (256 bits): VPU, DIV/SQRT
FP1 (256 bits): VPU, DIV/SQRT
FP2 (256 bits): VPU
FP3 (256 bits): VPU
FP4 (256 bits): FP store data
FP5 (256 bits): FP store data

Cycles executing div or sqrt instructions

NA

Cycles summary

Front-end	5.17
Dispatch	2.50
Overall L1	5.17

Vectorization ratios

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

Vector efficiency ratios

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

Cycles and memory resources usage

Assuming all data fit into the L1 cache, each call to the function takes 5.17 cycles. At this rate:

3% of peak load performance is reached (3.10 out of 96.00 bytes loaded per cycle (GB/s @ 1GHz))

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 5.17 to 2.50 cycles (2.07x speedup).

ASM code

In the binary file, the address of the function is: 9eaa0

Instruction	Nb FU	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5	Latency	Recip. throughput
PUSH %RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
MOV %RSP,%RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
PUSH %R15	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R14	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R13	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R12	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %RAX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
MOV 0x30(%RDI),%R14	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	0	0	3	0.33
SUB 0x28(%RDI),%R14	1	0.25	0.25	0.25	0.25	0	0.33	0.33	0.33	0	0	0	0	0	0	1	0.33
SHR $0x2,%R14	1	0	0.50	0.50	0	0	0	0	0	0	0	0	0	0	0	1	0.50
TEST %R14D,%R14D	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	0	0	1	0.25
JLE 9ec11 <_ZN6Kripke12ParallelComm12testRecievesEv+0x171>	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	1	0.50-1
MOV %RDI,%RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
XOR %R12D,%R12D	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.25
NOPL (%RAX)	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09
JMP 9ec11 <_ZN6Kripke12ParallelComm12testRecievesEv+0x171>	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	0	1
ADD $0x8,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	0	0	1	0.25
POP %RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R12	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R13	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R14	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R15	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
RET	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	1	0.50
MOV %R13,%RDI	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
MOV %RAX,%RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
CALL a8b10 <@plt_start@+0x40>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0	0	0.50
MOV %RBX,%RDI	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
CALL a90e0 <@plt_start@+0x610>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0	0	0.50
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3

Source file and lines	ParallelComm.cpp:214-251
Module	libkripke.so

The function is defined in:

/beegfs/hackathon/users/eoseret/qaas_runs/170-850-6313/intel/Kripke/build/Kripke/src/Kripke/ParallelComm.cpp:214-241,251
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_construct.h:119
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ext/new_allocator.h:127,145
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_vector.h:919,1046
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_algobase.h:429-431,911-912,1115
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_iterator.h:1028,1091,1182
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/vector.tcc:174-176

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is not vectorized. Only 10% of vector register length is used (average across all SSE/AVX instructions). By vectorizing your function, you can lower the cost of an iteration from 5.17 to 0.35 cycles (14.96x 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

CALL instructions

Detected function call instructions.

Details

Calling (and then returning from) a function prevents many compiler optimizations (like vectorization), breaks control flow (which reduces pipeline performance) and executes extra instructions to save/restore the registers used inside it, which is very expensive (dozens of cycles). Consider to inline small functions.

unknown: 2 occurrences

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 is loading 16 bytes.

General properties

nb instructions	43
nb uops	31
loop length	97
used x86 registers	9
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	5.17 cycles
front end	5.17 cycles

Back-end

	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5
uops	2.50	1.50	1.25	1.25	2.50	1.33	1.33	1.33	0.00	0.00	0.00	0.00	0.00	0.00
cycles	2.50	1.50	1.25	1.25	2.50	1.33	1.33	1.33	0.00	0.00	0.00	0.00	0.00	0.00

Execution ports to units layout:

ALU0/BRU0: ALU
ALU1: ALU
ALU2: ALU
ALU3: ALU
BRU1:
AGU0 (256 bits): store address, load
AGU1 (256 bits): store address, load
AGU2 (256 bits): store address, load
FP0 (256 bits): VPU, DIV/SQRT
FP1 (256 bits): VPU, DIV/SQRT
FP2 (256 bits): VPU
FP3 (256 bits): VPU
FP4 (256 bits): FP store data
FP5 (256 bits): FP store data

Cycles executing div or sqrt instructions

NA

Cycles summary

Front-end	5.17
Dispatch	2.50
Overall L1	5.17

Vectorization ratios

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

Vector efficiency ratios

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

Cycles and memory resources usage

Assuming all data fit into the L1 cache, each call to the function takes 5.17 cycles. At this rate:

3% of peak load performance is reached (3.10 out of 96.00 bytes loaded per cycle (GB/s @ 1GHz))

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 5.17 to 2.50 cycles (2.07x speedup).

ASM code

In the binary file, the address of the function is: 9eaa0

Instruction	Nb FU	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5	Latency	Recip. throughput
PUSH %RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
MOV %RSP,%RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
PUSH %R15	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R14	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R13	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %R12	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
PUSH %RAX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.50
MOV 0x30(%RDI),%R14	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	0	0	3	0.33
SUB 0x28(%RDI),%R14	1	0.25	0.25	0.25	0.25	0	0.33	0.33	0.33	0	0	0	0	0	0	1	0.33
SHR $0x2,%R14	1	0	0.50	0.50	0	0	0	0	0	0	0	0	0	0	0	1	0.50
TEST %R14D,%R14D	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	0	0	1	0.25
JLE 9ec11 <_ZN6Kripke12ParallelComm12testRecievesEv+0x171>	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	1	0.50-1
MOV %RDI,%RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
XOR %R12D,%R12D	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.25
NOPL (%RAX)	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09
JMP 9ec11 <_ZN6Kripke12ParallelComm12testRecievesEv+0x171>	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	0	1
ADD $0x8,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	0	0	1	0.25
POP %RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R12	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R13	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R14	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %R15	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
POP %RBP	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0.33
RET	1	0.50	0	0	0	0.50	0	0	0	0	0	0	0	0	0	1	0.50
MOV %R13,%RDI	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
MOV %RAX,%RBX	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
CALL a8b10 <@plt_start@+0x40>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0	0	0.50
MOV %RBX,%RDI	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
CALL a90e0 <@plt_start@+0x610>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0	0	0.50
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3
INT $0x3

▶Scalability Runs Description

Run 2x1	Number processes: 2Number nodes: 1Number processes per node: 2Run Command: <executable> --groups 1024 --procs 2,1,1MPI Command: mpirun -np <number_processes>Dataset: Run Directory: /beegfs/hackathon/users/eoseret/qaas_runs/170-850-6313/intel/Kripke/run/oneview_runs/compilers/aocc_10/oneview_run_1708510900I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spreadOMP_NUM_THREADS: 1
Run 2x2	OMP_NUM_THREADS: 2I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x4	OMP_NUM_THREADS: 4I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x8	OMP_NUM_THREADS: 8I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x16	OMP_NUM_THREADS: 16I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x32	OMP_NUM_THREADS: 32I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x64	OMP_NUM_THREADS: 64I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread
Run 2x96	OMP_NUM_THREADS: 96I_MPI_PIN_DOMAIN: auto:scatterOMP_PLACES: threadsOMP_PROC_BIND: spread

(2x1) Efficiency	(2x1) Potential Speed-Up (%)	(2x2) Efficiency	(2x2) Potential Speed-Up (%)	(2x4) Efficiency	(2x4) Potential Speed-Up (%)	(2x8) Efficiency	(2x8) Potential Speed-Up (%)	(2x16) Efficiency	(2x16) Potential Speed-Up (%)	(2x32) Efficiency	(2x32) Potential Speed-Up (%)	(2x64) Efficiency	(2x64) Potential Speed-Up (%)	(2x96) Efficiency	(2x96) Potential Speed-Up (%)
1	0	1.5	0	2.63	0	1	0	1	0	1	0	1	0	1	0

Speed-Up and Efficiency

▶Detailed Speed-Up and Efficiency

Run	Number of threads	Efficiency (ideal is 1)	Speedup	Ideal Speedup	Time (s)	Coverage (%)
2x1	1	1	1	1	0.84	0.04
2x2	1	1.5	3	2	0.55	0.02
2x4	1	2.63	10.5	4	0.28	0.01
2x8	1	1	1	8	0.07	0
2x16	2	1	1	16	0.01	0
2x32	2	1	1	32	0.04	0
2x64	1	1	1	64	0.23	0.01
2x96	1	1	1	96	0.32	0.01

Name	Coverage (%)	Time (s)
▼_ZN6Kripke12ParallelComm12testRecievesEv–	0.04	0.42
▼Loop 1356 - ParallelComm.cpp:219-241 - libkripke.so–	0	0.07
○Loop 1358 - stl_algobase.h:911-912 - libkripke.so	0.03	0.65
○Loop 1357 - ParallelComm.cpp:239-240 - libkripke.so	0	0

Report Configuration

Vectorization

Details

Workaround

Execution units bottlenecks

CALL instructions

Details

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

CALL instructions

Details

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

▶Scalability Runs Description

▼Colums Filter

Speed-Up and Efficiency

▶Detailed Speed-Up and Efficiency