OV - - Function gasdev.A

/beegfs/hackathon/users/eoseret/qaas_runs/170-850-7424/intel/CoMD/build/CoMD/CoMD/src-openmp/random.c: 22 - 48

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

22: {

23:    real_t rsq,v1,v2;

24:    do

25:    {

26:       v1 = 2.0*lcg61(seed)-1.0;

27:       v2 = 2.0*lcg61(seed)-1.0;

28:       rsq = v1*v1+v2*v2;

29:    } while (rsq >= 1.0 || rsq == 0.0);

30:

31:    return v2 * sqrt(-2.0*log(rsq)/rsq);

[...]

45:    *seed *= UINT64_C(437799614237992725);

46:    *seed %= UINT64_C(2305843009213693951);

47:

48:    return *seed*convertToDouble;

0x417750 MOV	$0x613606df9756715,%R8

0x41775a MOV	(%RDI),%RCX

0x41775d MOV	$0x9,%R9D

0x417763 MOVAPD	0x16625(%RIP),%XMM6

0x41776b MOVAPD	0x1662d(%RIP),%XMM1

0x417773 MOVSD	0x13c05(%RIP),%XMM2

0x41777b XORPD	%XMM3,%XMM3

0x41777f NOP

(148) 0x417780 IMUL	%R8,%RCX

(148) 0x417784 MOV	%RCX,%RAX

(148) 0x417787 MUL	%R9

(148) 0x41778a MOV	%RCX,%RSI

(148) 0x41778d SUB	%RDX,%RSI

(148) 0x417790 SHR	$0x1,%RSI

(148) 0x417793 ADD	%RDX,%RSI

(148) 0x417796 SHR	$0x3c,%RSI

(148) 0x41779a MOV	%RSI,%RAX

(148) 0x41779d SAL	$0x3d,%RAX

(148) 0x4177a1 SUB	%RAX,%RSI

(148) 0x4177a4 ADD	%RCX,%RSI

(148) 0x4177a7 XORPS	%XMM4,%XMM4

(148) 0x4177aa CVTSI2SD	%RSI,%XMM4

(148) 0x4177af IMUL	%R8,%RSI

(148) 0x4177b3 MOV	%RSI,%RAX

(148) 0x4177b6 MUL	%R9

(148) 0x4177b9 MOV	%RSI,%RCX

(148) 0x4177bc SUB	%RDX,%RCX

(148) 0x4177bf SHR	$0x1,%RCX

(148) 0x4177c2 ADD	%RDX,%RCX

(148) 0x4177c5 SHR	$0x3c,%RCX

(148) 0x4177c9 MOV	%RCX,%RAX

(148) 0x4177cc SAL	$0x3d,%RAX

(148) 0x4177d0 SUB	%RAX,%RCX

(148) 0x4177d3 ADD	%RSI,%RCX

(148) 0x4177d6 XORPS	%XMM5,%XMM5

(148) 0x4177d9 CVTSI2SD	%RCX,%XMM5

(148) 0x4177de UNPCKLPD	%XMM4,%XMM5

(148) 0x4177e2 MULPD	%XMM6,%XMM5

(148) 0x4177e6 ADDPD	%XMM1,%XMM5

(148) 0x4177ea MOVAPD	%XMM5,%XMM4

(148) 0x4177ee MULPD	%XMM5,%XMM4

(148) 0x4177f2 MOVAPD	%XMM4,%XMM0

(148) 0x4177f6 UNPCKHPD	%XMM4,%XMM0

(148) 0x4177fa ADDSD	%XMM4,%XMM0

(148) 0x4177fe UCOMISD	%XMM2,%XMM0

(148) 0x417802 JAE	417780

(148) 0x417808 UCOMISD	%XMM3,%XMM0

(148) 0x41780c JE	417780

0x417812 PUSH	%RBP

0x417813 MOV	%RSP,%RBP

0x417816 SUB	$0x20,%RSP

0x41781a MOV	%RCX,(%RDI)

0x41781d MOVAPD	%XMM5,-0x20(%RBP)

0x417822 MOVAPD	%XMM0,-0x10(%RBP)

0x417827 CALL	418d10 <log>

0x41782c MULSD	0x1657c(%RIP),%XMM0

0x417834 DIVSD	-0x10(%RBP),%XMM0

0x417839 SQRTSD	%XMM0,%XMM0

0x41783d MULSD	-0x20(%RBP),%XMM0

0x417842 ADD	$0x20,%RSP

0x417846 POP	%RBP

0x417847 RET

0x417848 NOPL	(%RAX,%RAX,1)

Path /

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

Source file and lines	random.c:22-48
Module	exec

The function is defined in /beegfs/hackathon/users/eoseret/qaas_runs/170-850-7424/intel/CoMD/build/CoMD/CoMD/src-openmp/random.c:22-31,45-48.

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is poorly vectorized. Only 16% of vector register length is used (average across all SSE/AVX instructions). By fully vectorizing your function, you can lower the cost of an iteration from 13.50 to 3.37 cycles (4.00x speedup).

Details

35% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):

28% of SSE/AVX loads are used in vector version.
66% of SSE/AVX stores are used in vector version.
0% of SSE/AVX multiply instructions are used in vector version.
0% of SSE/AVX divide and square root instructions are used in vector version.
33% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.

Since your execution units are vector units, only a fully 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

Performance is limited by execution of divide and square root operations (the divide/square root unit is a bottleneck). By removing all these bottlenecks, you can lower the cost of an iteration from 13.50 to 3.67 cycles (3.68x speedup).

Workaround

Reduce the number of division or square root instructions:
- If denominator is constant over iterations, use reciprocal (replace x/y with x*(1/y)). Check precision impact. This will be done by your compiler with ffast-math or Ofast
Check whether you really need double precision. If not, switch to single precision to speedup execution

Expensive FP math instructions/calls

Detected performance impact from expensive FP math instructions/calls. By removing/reexpressing them, you can lower the cost of an iteration from 13.50 to 3.67 cycles (3.68x speedup).

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.

log: 1 occurrences

Type of elements and instruction set

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

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

The binary function is composed of 4 FP arithmetical operations:

2: multiply
1: divide
1: square root

The binary function is loading 72 bytes (9 double precision FP elements). The binary function is storing 40 bytes (5 double precision FP elements).

Arithmetic intensity

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

General properties

nb instructions	23
nb uops	22
loop length	110
used x86 registers	7
used mmx registers	0
used xmm registers	6
used ymm registers	0
used zmm registers	0
nb stack references	2

Front-end

MACRO FUSION NOT POSSIBLE FIT IN UOP CACHE

micro-operation queue	3.67 cycles
front end	3.67 cycles

Back-end

	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5
uops	1.25	1.25	1.25	1.25	1.00	3.67	3.67	3.67	2.00	2.00	0.00	0.00	1.00	1.00
cycles	1.25	1.25	1.25	1.25	1.00	3.67	3.67	3.67	2.00	2.00	0.00	0.00	1.00	1.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

13.50

Cycles summary

Front-end	3.67
Dispatch	3.67
DIV/SQRT	13.50
Overall L1	13.50

Vectorization ratios

INT

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

FP

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

INT+FP

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

Vector efficiency ratios

INT

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

FP

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

INT+FP

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

Cycles and memory resources usage

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

5% of peak load performance is reached (5.33 out of 96.00 bytes loaded per cycle (GB/s @ 1GHz))
4% of peak store performance is reached (2.96 out of 64.00 bytes stored per cycle (GB/s @ 1GHz))

Front-end bottlenecks

Found no such bottlenecks.

ASM code

In the binary file, the address of the function is: 417750

Instruction	Nb FU	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP4	FP5	Latency	Recip. throughput
MOV $0x613606df9756715,%R8	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.33
MOV (%RDI),%RCX	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.33
MOV $0x9,%R9D	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
MOVAPD 0x16625(%RIP),%XMM6	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.50
MOVAPD 0x1662d(%RIP),%XMM1	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.50
MOVSD 0x13c05(%RIP),%XMM2	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	1	0.50
XORPD %XMM3,%XMM3	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
NOP	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09
PUSH %RBP	1	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.17
SUB $0x20,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
MOV %RCX,(%RDI)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	4	0.50
MOVAPD %XMM5,-0x20(%RBP)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0.50	0.50	4	1
MOVAPD %XMM0,-0x10(%RBP)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0.50	0.50	4	1
CALL 418d10 <log>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0.50
MULSD 0x1657c(%RIP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	3	0.50
DIVSD -0x10(%RBP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	13	5
SQRTSD %XMM0,%XMM0	1	0	0	0	0	0	0	0	0	0.50	0.50	0	0	21	8.50
MULSD -0x20(%RBP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	3	0.50
ADD $0x20,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
POP %RBP	1	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	1	0.50
NOPL (%RAX,%RAX,1)	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09

Source file and lines	random.c:22-48
Module	exec

The function is defined in /beegfs/hackathon/users/eoseret/qaas_runs/170-850-7424/intel/CoMD/build/CoMD/CoMD/src-openmp/random.c:22-31,45-48.

Warnings:
Ignoring paths for analysis

gain
potential
hint
expert

Vectorization

Your function is poorly vectorized. Only 16% of vector register length is used (average across all SSE/AVX instructions). By fully vectorizing your function, you can lower the cost of an iteration from 13.50 to 3.37 cycles (4.00x speedup).

Details

35% of SSE/AVX instructions are used in vector version (process two or more data elements in vector registers):

28% of SSE/AVX loads are used in vector version.
66% of SSE/AVX stores are used in vector version.
0% of SSE/AVX multiply instructions are used in vector version.
0% of SSE/AVX divide and square root instructions are used in vector version.
33% of SSE/AVX instructions that are not load, store, addition, subtraction nor multiply instructions are used in vector version.

Since your execution units are vector units, only a fully 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

Performance is limited by execution of divide and square root operations (the divide/square root unit is a bottleneck). By removing all these bottlenecks, you can lower the cost of an iteration from 13.50 to 3.67 cycles (3.68x speedup).

Workaround

Reduce the number of division or square root instructions:
- If denominator is constant over iterations, use reciprocal (replace x/y with x*(1/y)). Check precision impact. This will be done by your compiler with ffast-math or Ofast
Check whether you really need double precision. If not, switch to single precision to speedup execution

Expensive FP math instructions/calls

Detected performance impact from expensive FP math instructions/calls. By removing/reexpressing them, you can lower the cost of an iteration from 13.50 to 3.67 cycles (3.68x speedup).

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.

log: 1 occurrences

Type of elements and instruction set

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

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

The binary function is composed of 4 FP arithmetical operations:

2: multiply
1: divide
1: square root

The binary function is loading 72 bytes (9 double precision FP elements). The binary function is storing 40 bytes (5 double precision FP elements).

Arithmetic intensity

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

General properties

nb instructions	23
nb uops	22
loop length	110
used x86 registers	7
used mmx registers	0
used xmm registers	6
used ymm registers	0
used zmm registers	0
nb stack references	2

Front-end

MACRO FUSION NOT POSSIBLE FIT IN UOP CACHE

micro-operation queue	3.67 cycles
front end	3.67 cycles

Back-end

	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP2	FP3	FP4	FP5
uops	1.25	1.25	1.25	1.25	1.00	3.67	3.67	3.67	2.00	2.00	0.00	0.00	1.00	1.00
cycles	1.25	1.25	1.25	1.25	1.00	3.67	3.67	3.67	2.00	2.00	0.00	0.00	1.00	1.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

13.50

Cycles summary

Front-end	3.67
Dispatch	3.67
DIV/SQRT	13.50
Overall L1	13.50

Vectorization ratios

INT

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

FP

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

INT+FP

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

Vector efficiency ratios

INT

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

FP

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

INT+FP

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

Cycles and memory resources usage

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

5% of peak load performance is reached (5.33 out of 96.00 bytes loaded per cycle (GB/s @ 1GHz))
4% of peak store performance is reached (2.96 out of 64.00 bytes stored per cycle (GB/s @ 1GHz))

Front-end bottlenecks

Found no such bottlenecks.

ASM code

In the binary file, the address of the function is: 417750

Instruction	Nb FU	ALU0/BRU0	ALU1	ALU2	ALU3	BRU1	AGU0	AGU1	AGU2	FP0	FP1	FP4	FP5	Latency	Recip. throughput
MOV $0x613606df9756715,%R8	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.33
MOV (%RDI),%RCX	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.33
MOV $0x9,%R9D	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
MOVAPD 0x16625(%RIP),%XMM6	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.50
MOVAPD 0x1662d(%RIP),%XMM1	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	3	0.50
MOVSD 0x13c05(%RIP),%XMM2	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	1	0.50
XORPD %XMM3,%XMM3	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0.17
NOP	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09
PUSH %RBP	1	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.17
SUB $0x20,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
MOV %RCX,(%RDI)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0	0	4	0.50
MOVAPD %XMM5,-0x20(%RBP)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0.50	0.50	4	1
MOVAPD %XMM0,-0x10(%RBP)	1	0	0	0	0	0	0.33	0.33	0.33	0	0	0.50	0.50	4	1
CALL 418d10 <log>	2	0.50	0	0	0	0.50	0.33	0.33	0.33	0	0	0	0	0	0.50
MULSD 0x1657c(%RIP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	3	0.50
DIVSD -0x10(%RBP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	13	5
SQRTSD %XMM0,%XMM0	1	0	0	0	0	0	0	0	0	0.50	0.50	0	0	21	8.50
MULSD -0x20(%RBP),%XMM0	1	0	0	0	0	0	0.33	0.33	0.33	0.50	0.50	0	0	3	0.50
ADD $0x20,%RSP	1	0.25	0.25	0.25	0.25	0	0	0	0	0	0	0	0	1	0.25
POP %RBP	1	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	1	0.50
NOPL (%RAX,%RAX,1)	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0.09

▶Scalability Runs Description

Run 2x1	Number processes: 1Number nodes: 1Run Command: <executable> -x 100 -y 100 -z 100 --xproc=2 --yproc=1 --zproc=1MPI Command: mpirun -np 2Dataset: Run Directory: /beegfs/hackathon/users/eoseret/qaas_runs/170-850-7424/intel/CoMD/run/oneview_runs/compilers/icx_6/oneview_run_1708509234I_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.1	-0	0.92	0	1.38	0	0.69	0.01	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	2	1	1	1	0.12	0.04
2x2	4	1.1	2.2	2	0.07	0.04
2x4	8	0.92	3.67	4	0.03	0.03
2x8	16	1.38	11	8	0.02	0.03
2x16	32	0.69	11	16	0.01	0.02
2x32	64	1	1	32	0.01	0.01
2x64	119	1	1	64	0	0
2x96	165	1	1	96	0	0

Name	Coverage (%)	Time (s)
▼gasdev.A–	0.04	0.11
○Loop 148 - random.c:27-48 - exec	0.02	0.07

Report Configuration

Vectorization

Details

Workaround

Execution units bottlenecks

Workaround

Expensive FP math instructions/calls

CALL instructions

Details

Type of elements and instruction set

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

Arithmetic intensity

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

Workaround

Expensive FP math instructions/calls

CALL instructions

Details

Type of elements and instruction set

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

Arithmetic intensity

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