关于C#：在L1缓存中的Haswell上获得峰值带宽：仅获得62％

Obtaining peak bandwidth on Haswell in the L1 cache: only getting 62%

我正在尝试在L1高速缓存中获取完整带宽，以用于Intel处理器上的以下功能

好的。

1
2
3
4
5
6

float triad(float *x, float *y, float *z, const int n) {
float k = 3.14159f;
for(int i=0; i<n; i++) {
z[i] = x[i] + k*y[i];
}
}

这是来自STREAM的三合会功能。

好的。

使用具有此功能的SandyBridge / IvyBridge处理器(与NASM配合使用)，可以得到约95％的峰。但是，使用Haswell只能达到峰值的62％，除非展开循环。如果我解开16次，我将得到92％。我不明白

好的。

我决定使用NASM在汇编中编写函数。汇编中的主循环如下所示。

好的。

1
2
3
4
5
6

.L2:
vmovaps ymm1, [rdi+rax]
vfmadd231ps ymm1, ymm2, [rsi+rax]
vmovaps [rdx+rax], ymm1
add rax, 32
jne .L2

在Agner Fog的"优化组装"手册的示例12.7-12.11中，他对Pentium M，Core 2，Sandy Bridge，FMA4和FMA3所做的操作几乎相同(但对于y[i] = y[i] +k*x[i]而言)。我设法自己或多或少地复制了他的代码(实际上，当他广播时，他在FMA3示例中有一个小错误)。他在表中给出了每个处理器(FMA4和FMA3除外)的指令大小计数，融合操作，执行端口。我尝试自己为FMA3制作这张桌子。

好的。

1
2
3
4
5
6
7
8
9

ports
size μops-fused 0 1 2 3 4 5 6 7
vmovaps 5 1 ? ?
vfmadd231ps 6 1 ? ? ? ?
vmovaps 5 1 1 1
add 4 ? ?
jne 2 ? ?
--------------------------------------------------------------
total 22 4 ? ? 1 1 1 0 1 1

大小是指指令长度(以字节为单位)。 add和jne指令具有半个μop的原因是它们被融合为一个宏操作(不要与仍然使用多个端口的μop融合相混淆)，并且只需要端口6和一个μop。 vfmadd231ps指令可以使用端口0或端口1。我选择端口0。负载vmovaps可以使用端口2或3。我选择2，让vfmadd231ps使用端口3。。为了与Agner Fog的表保持一致，并且由于我认为说一条可以平均分配到不同端口的指令的使用时间是每1/2的时间更有意义，因此我为端口vmovaps分配了1/2和vmadd231ps可以转到。

好的。

根据该表以及所有Core2处理器每个时钟周期都可以执行4μop的事实，看来该循环应该在每个时钟周期都可以实现，但是我还没有设法获得它。有人可以向我解释为什么我不能不展开就无法接近Haswell上此功能的峰值带宽吗？如果不展开就可以吗？如果可以，怎么办？让我清楚一点，我实际上是在尝试为此功能最大化ILP(我不仅想要最大的带宽)，所以这就是我不想展开的原因。

好的。

编辑：
这是自Iwillnotexist Idonotexist使用IACA表示商店从未使用端口7以来的更新。我设法在不展开的情况下突破了66％的限制，并且在每次迭代中都在一个时钟周期内完成了理论上的展开(理论上)。让我们首先解决商店问题。

好的。

Stephen Canon在评论中提到，端口7中的地址生成单元(AGU)只能处理诸如[base + offset]而不是[base + index]之类的简单操作。在英特尔优化参考手册中，我发现的唯一内容是对port7的注释，其中显示" Simple_AGU"，但未定义简单含义。但是随后Iwillnotexist Idonotexist在IACA的评论中发现，六个月前已经提到了此问题，英特尔的一名员工在2014年11月11日写道：

好的。

Port7 AGU can only work on stores with simple memory address (no index register).

Ok.

Stephen Canon建议"将存储地址用作加载操作数的偏移量"。我已经这样尝试过

好的。

1
2
3
4
5
6

vmovaps ymm1, [rdi + r9 + 32*i]
vfmadd231ps ymm1, ymm2, [rsi + r9 + 32*i]
vmovaps [r9 + 32*i], ymm1
add r9, 32*unroll
cmp r9, rcx
jne .L2

这确实导致商店使用端口7。但是，另一个问题是vmadd231ps不能与您从IACA中看到的负载融合。它还需要我的原始功能不需要的cmp指令。因此，商店使用的微操作数量少了一个，而cmp(或者是add，因为cmp宏与jne融合在一起)需要一个。 IACA报告的块吞吐量为1.5。实际上，这仅达到峰值的57％。

好的。

但是我找到了一种方法来使vmadd231ps指令也与负载融合。只能使用带有寻址[静态32位地址+索引]这样的静态数组来完成此操作。 Evgeny Kluev最初提出了这一建议。

好的。

1
2
3
4
5

vmovaps ymm1, [src1_end + rax]
vfmadd231ps ymm1, ymm2, [src2_end + rax]
vmovaps [dst_end + rax], ymm1
add rax, 32
jl .L2

其中src1_end，src2_end和dst_end是静态数组的结束地址。

好的。

这重现了我所问问题的表格，其中包含我期望的四个融合微操作。如果将此内容放入IACA，则报告的块吞吐量为1.0。从理论上讲，这应该与SSE和AVX版本一样好。实际上，它达到峰值的72％。这打破了66％的壁垒，但距离我展开16次的92％的差距还有很长的路要走。因此，在Haswell上接近峰顶的唯一选择是展开。通过Ivy Bridge在Core2上不需要这样做，但在Haswell上则不需要。

好的。

结束编辑：

好的。

这是C / C ++ Linux代码进行测试。 NASM代码在C / C ++代码之后发布。您唯一需要更改的是频率编号。在double frequency = 1.3;行中，将1.3替换为您的处理器的运行(非标称)频率(对于在BIOS中禁用了Turbo的i5-4250U，则为1.3 GHz)。

好的。

编译

好的。

1
2
3
4
5
6

nasm -f elf64 triad_sse_asm.asm
nasm -f elf64 triad_avx_asm.asm
nasm -f elf64 triad_fma_asm.asm
g++ -m64 -lrt -O3 -mfma tests.cpp triad_fma_asm.o -o tests_fma
g++ -m64 -lrt -O3 -mavx tests.cpp triad_avx_asm.o -o tests_avx
g++ -m64 -lrt -O3 -msse2 tests.cpp triad_sse_asm.o -o tests_sse

C / C ++代码

好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

#include <x86intrin.h>
#include <stdio.h>
#include <string.h>
#include <time.h>

#define TIMER_TYPE CLOCK_REALTIME

extern"C" float triad_sse_asm_repeat(float *x, float *y, float *z, const int n, int repeat);
extern"C" float triad_sse_asm_repeat_unroll16(float *x, float *y, float *z, const int n, int repeat);
extern"C" float triad_avx_asm_repeat(float *x, float *y, float *z, const int n, int repeat);
extern"C" float triad_avx_asm_repeat_unroll16(float *x, float *y, float *z, const int n, int repeat);
extern"C" float triad_fma_asm_repeat(float *x, float *y, float *z, const int n, int repeat);
extern"C" float triad_fma_asm_repeat_unroll16(float *x, float *y, float *z, const int n, int repeat);

#if (defined(__FMA__))
float triad_fma_repeat(float *x, float *y, float *z, const int n, int repeat) {
float k = 3.14159f;
int r;
for(r=0; r<repeat; r++) {
int i;
__m256 k4 = _mm256_set1_ps(k);
for(i=0; i<n; i+=8) {
_mm256_store_ps(&z[i], _mm256_fmadd_ps(k4, _mm256_load_ps(&y[i]), _mm256_load_ps(&x[i])));
}
}
}
#elif (defined(__AVX__))
float triad_avx_repeat(float *x, float *y, float *z, const int n, int repeat) {
float k = 3.14159f;
int r;
for(r=0; r<repeat; r++) {
int i;
__m256 k4 = _mm256_set1_ps(k);
for(i=0; i<n; i+=8) {
_mm256_store_ps(&z[i], _mm256_add_ps(_mm256_load_ps(&x[i]), _mm256_mul_ps(k4, _mm256_load_ps(&y[i]))));
}
}
}
#else
float triad_sse_repeat(float *x, float *y, float *z, const int n, int repeat) {
float k = 3.14159f;
int r;
for(r=0; r<repeat; r++) {
int i;
__m128 k4 = _mm_set1_ps(k);
for(i=0; i<n; i+=4) {
_mm_store_ps(&z[i], _mm_add_ps(_mm_load_ps(&x[i]), _mm_mul_ps(k4, _mm_load_ps(&y[i]))));
}
}
}
#endif

double time_diff(timespec start, timespec end)
{
timespec temp;
if ((end.tv_nsec-start.tv_nsec)<0) {
temp.tv_sec = end.tv_sec-start.tv_sec-1;
temp.tv_nsec = 1000000000+end.tv_nsec-start.tv_nsec;
} else {
temp.tv_sec = end.tv_sec-start.tv_sec;
temp.tv_nsec = end.tv_nsec-start.tv_nsec;
}
return (double)temp.tv_sec + (double)temp.tv_nsec*1E-9;
}

int main () {
int bytes_per_cycle = 0;
double frequency = 1.3; //Haswell
//double frequency = 3.6; //IB
//double frequency = 2.66; //Core2
#if (defined(__FMA__))
bytes_per_cycle = 96;
#elif (defined(__AVX__))
bytes_per_cycle = 48;
#else
bytes_per_cycle = 24;
#endif
double peak = frequency*bytes_per_cycle;

const int n =2048;

float* z2 = (float*)_mm_malloc(sizeof(float)*n, 64);
char *mem = (char*)_mm_malloc(1<<18,4096);
char *a = mem;
char *b = a+n*sizeof(float);
char *c = b+n*sizeof(float);

float *x = (float*)a;
float *y = (float*)b;
float *z = (float*)c;

for(int i=0; i<n; i++) {
x[i] = 1.0f*i;
y[i] = 1.0f*i;
z[i] = 0;
}
int repeat = 1000000;
timespec time1, time2;
#if (defined(__FMA__))
triad_fma_repeat(x,y,z2,n,repeat);
#elif (defined(__AVX__))
triad_avx_repeat(x,y,z2,n,repeat);
#else
triad_sse_repeat(x,y,z2,n,repeat);
#endif

while(1) {
double dtime, rate;

clock_gettime(TIMER_TYPE, &time1);
#if (defined(__FMA__))
triad_fma_asm_repeat(x,y,z,n,repeat);
#elif (defined(__AVX__))
triad_avx_asm_repeat(x,y,z,n,repeat);
#else
triad_sse_asm_repeat(x,y,z,n,repeat);
#endif
clock_gettime(TIMER_TYPE, &time2);
dtime = time_diff(time1,time2);
rate = 3.0*1E-9*sizeof(float)*n*repeat/dtime;
printf("unroll1 rate %6.2f GB/s, efficency %6.2f%%, error %d\
", rate, 100*rate/peak, memcmp(z,z2, sizeof(float)*n));
clock_gettime(TIMER_TYPE, &time1);
#if (defined(__FMA__))
triad_fma_repeat(x,y,z,n,repeat);
#elif (defined(__AVX__))
triad_avx_repeat(x,y,z,n,repeat);
#else
triad_sse_repeat(x,y,z,n,repeat);
#endif
clock_gettime(TIMER_TYPE, &time2);
dtime = time_diff(time1,time2);
rate = 3.0*1E-9*sizeof(float)*n*repeat/dtime;
printf("intrinsic rate %6.2f GB/s, efficency %6.2f%%, error %d\
", rate, 100*rate/peak, memcmp(z,z2, sizeof(float)*n));
clock_gettime(TIMER_TYPE, &time1);
#if (defined(__FMA__))
triad_fma_asm_repeat_unroll16(x,y,z,n,repeat);
#elif (defined(__AVX__))
triad_avx_asm_repeat_unroll16(x,y,z,n,repeat);
#else
triad_sse_asm_repeat_unroll16(x,y,z,n,repeat);
#endif
clock_gettime(TIMER_TYPE, &time2);
dtime = time_diff(time1,time2);
rate = 3.0*1E-9*sizeof(float)*n*repeat/dtime;
printf("unroll16 rate %6.2f GB/s, efficency %6.2f%%, error %d\
", rate, 100*rate/peak, memcmp(z,z2, sizeof(float)*n));
}
}

使用System V AMD64 ABI的NASM代码。

好的。

triad_fma_asm.asm：

好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

global triad_fma_asm_repeat
;RDI x, RSI y, RDX z, RCX n, R8 repeat
;z[i] = y[i] + 3.14159*x[i]
pi: dd 3.14159
;align 16
section .text
triad_fma_asm_repeat:
shl rcx, 2
add rdi, rcx
add rsi, rcx
add rdx, rcx
vbroadcastss ymm2, [rel pi]
;neg rcx

align 16
.L1:
mov rax, rcx
neg rax
align 16
.L2:
vmovaps ymm1, [rdi+rax]
vfmadd231ps ymm1, ymm2, [rsi+rax]
vmovaps [rdx+rax], ymm1
add rax, 32
jne .L2
sub r8d, 1
jnz .L1
vzeroupper
ret

global triad_fma_asm_repeat_unroll16
section .text
triad_fma_asm_repeat_unroll16:
shl rcx, 2
add rcx, rdi
vbroadcastss ymm2, [rel pi]
.L1:
xor rax, rax
mov r9, rdi
mov r10, rsi
mov r11, rdx
.L2:
%assign unroll 32
%assign i 0
%rep unroll
vmovaps ymm1, [r9 + 32*i]
vfmadd231ps ymm1, ymm2, [r10 + 32*i]
vmovaps [r11 + 32*i], ymm1
%assign i i+1
%endrep
add r9, 32*unroll
add r10, 32*unroll
add r11, 32*unroll
cmp r9, rcx
jne .L2
sub r8d, 1
jnz .L1
vzeroupper
ret

triad_ava_asm.asm：

好的。

global triad_avx_asm_repeat
;RDI x, RSI y, RDX z, RCX n, R8 repeat
pi: dd 3.14159
align 16
section .text
triad_avx_asm_repeat:
shl rcx, 2
add rdi, rcx
add rsi, rcx
add rdx, rcx
vbroadcastss ymm2, [rel pi]
;neg rcx

align 16
.L1:
mov rax, rcx
neg rax
align 16
.L2:
vmulps ymm1, ymm2, [rdi+rax]
vaddps ymm1, ymm1, [rsi+rax]
vmovaps [rdx+rax], ymm1
add rax, 32
jne .L2
sub r8d, 1
jnz .L1
vzeroupper
ret

global triad_avx_asm_repeat2
;RDI x, RSI y, RDX z, RCX n, R8 repeat
;pi: dd 3.14159
align 16
section .text
triad_avx_asm_repeat2:
shl rcx, 2
vbroadcastss ymm2, [rel pi]

align 16
.L1:
xor rax, rax
align 16
.L2:
vmulps ymm1, ymm2, [rdi+rax]
vaddps ymm1, ymm1, [rsi+rax]
vmovaps [rdx+rax], ymm1
add eax, 32
cmp eax, ecx
jne .L2
sub r8d, 1
jnz .L1
vzeroupper
ret

global triad_avx_asm_repeat_unroll16
align 16
section .text
triad_avx_asm_repeat_unroll16:
shl rcx, 2
add rcx, rdi
vbroadcastss ymm2, [rel pi]
align 16
.L1:
xor rax, rax
mov r9, rdi
mov r10, rsi
mov r11, rdx
align 16
.L2:
%assign unroll 16
%assign i 0
%rep unroll
vmulps ymm1, ymm2, [r9 + 32*i]
vaddps ymm1, ymm1, [r10 + 32*i]
vmovaps [r11 + 32*i], ymm1
%assign i i+1
%endrep
add r9, 32*unroll
add r10, 32*unroll
add r11, 32*unroll
cmp r9, rcx
jne .L2
sub r8d, 1
jnz .L1
vzeroupper
ret

triad_sse_asm.asm：

好的。

global triad_sse_asm_repeat
;RDI x, RSI y, RDX z, RCX n, R8 repeat
pi: dd 3.14159
;align 16
section .text
triad_sse_asm_repeat:
shl rcx, 2
add rdi, rcx
add rsi, rcx
add rdx, rcx
movss xmm2, [rel pi]
shufps xmm2, xmm2, 0
;neg rcx
align 16
.L1:
mov rax, rcx
neg rax
align 16
.L2:
movaps xmm1, [rdi+rax]
mulps xmm1, xmm2
addps xmm1, [rsi+rax]
movaps [rdx+rax], xmm1
add rax, 16
jne .L2
sub r8d, 1
jnz .L1
ret

global triad_sse_asm_repeat2
;RDI x, RSI y, RDX z, RCX n, R8 repeat
;pi: dd 3.14159
;align 16
section .text
triad_sse_asm_repeat2:
shl rcx, 2
movss xmm2, [rel pi]
shufps xmm2, xmm2, 0
align 16
.L1:
xor rax, rax
align 16
.L2:
movaps xmm1, [rdi+rax]
mulps xmm1, xmm2
addps xmm1, [rsi+rax]
movaps [rdx+rax], xmm1
add eax, 16
cmp eax, ecx
jne .L2
sub r8d, 1
jnz .L1
ret

global triad_sse_asm_repeat_unroll16
section .text
triad_sse_asm_repeat_unroll16:
shl rcx, 2
add rcx, rdi
movss xmm2, [rel pi]
shufps xmm2, xmm2, 0
.L1:
xor rax, rax
mov r9, rdi
mov r10, rsi
mov r11, rdx
.L2:
%assign unroll 8
%assign i 0
%rep unroll
movaps xmm1, [r9 + 16*i]
mulps xmm1, xmm2,
addps xmm1, [r10 + 16*i]
movaps [r11 + 16*i], xmm1
%assign i i+1
%endrep
add r9, 16*unroll
add r10, 16*unroll
add r11, 16*unroll
cmp r9, rcx
jne .L2
sub r8d, 1
jnz .L1
ret

好。

相关讨论

@dolan我有两个32字节的负载，一个32字节的写入，一个32字节的FMA，一个64位加法，以及一个条件分支，该分支总共使用4个融合的微操作和6/8端口。我还能做什么指令级并行性？
出于好奇：您如何衡量帖子中提到的峰值带宽的百分比？
@rubenvb，其在double rate = 3.0*1E-9*sizeof(float)*n*repeatdtime;行中完成。百分比为100*ratepeak。峰值为frequency*96，在我的情况下为1.3*96=124.8 billion bytessec。 96是32 * 2字节读取+ 32 * 1字节写入。
我想你应该问一下Mysticial
可以在stackoverflow.com/questions/25921612/上找到SSE，AVX和FMA的结果表。您可以在Haswell上清楚地看到问题所在。
为了使FMA版本以100％运行，它需要在每个周期使所有8个端口饱和。 (0 + 1-2xFMA，2 + 3-2xload，7 + 4、1xstore，5-添加，6-jmp)。此外，您在未融合域中总共有6 uops，在融合域中总共有4 uops。 Haswell每个周期只能退休4 oups，但尚不清楚其4在融合域还是未融合域中。即使我们假设是前者，阿格纳·福格(Agner Fog)表示，基本上不可能在每个周期维持所有8个端口。
假设add / jmp被融合，您仍然需要在每个周期维持8个端口中的7个。问题在于某些指令可以进入多个端口，CPU必须最佳地选择正确的指令以避免阻塞其他指令。最佳包装是NP完全问题，不是我希望处理器能够做到的事情。
@Mysticial，您认为值得把这个问题变成一个悬赏问题，还是我只是在浪费代表？
@Mysticial，我错过了必须饱和所有8个端口的部分。那是我需要阅读的好点。在我上面的表格中，它使用了六个端口，我可以选择一些变化。
您可能需要英特尔的人来给您一个明确的答案。我只是说我只能找到1个可以达到100％的调度(假设4个限制用于融合的uops)。但是，由于有太多的调度方法，因此处理器可能实际上找不到最佳的调度方法。例如，商店需要237 +4。它可以在2、3或7之间选择。但是，它必须选择7，否则将阻止负载。同样，融合的add / jmp可以输入0或6。但是必须选择6，否则将阻止FMA。
此外，如果您对同一端口发出两条延迟不同的指令，它们可能会在同一周期内完成。但是端口无法在同一周期上输出两件事，因此会冒泡。这在这里不是问题，因为最佳调度具有前往相同端口的相同指令。但是，一旦处理器做出错误的决定(例如将add / jmp放在端口0上)，它将开始引起气泡。
@Mysticial，为什么展开帮助。实际上，我必须展开很多工作。我什至没有达到高峰解开16次。我不知道出汗点在哪里，但是我完全展开了256次(8 * 256 = 2048)，这获得了我所见过的最高效率(但仍然只有93％)。
展开会有帮助，因为您没有添加和添加jmp的方法。假设，每当该对被调度到端口0中时，它将阻塞2个FMA。 (一次发出该周期，一次出现在同一周期结束的更早的FMA)
@Mysticial，好吧，这很有道理。我了解您所说的大部分内容。我需要更仔细地阅读它，并再次查看Agners手册。无论如何，我都会提出这个悬疑问题。我不是100％相信这是不可能的。好吧，我或多或少相信我不能像我那样做。但我认为，如果不进行大量部署，可能会超过93％。
@Mysticial @Z玻色子每篇由英特尔在Hot Chips上发表的论文，在第14页上，我们都有：每个周期最多四个复合操作分配用于乱序执行的资源，并分为简单操作。异构执行端口每个周期最多可以执行八个简单操作。完成后，每个周期最多可淘汰四个复合操作。每个Haswell内核都通过Intel超线程在两个执行线程之间共享其执行资源。我认为这意味着它的吞吐量为4融合uops /时钟周期
@Mysticial @Z玻色子用尽了所有可能导致此问题的想法。即使将vfmadd231ps ymm1, ymm2, [rsi+rax]替换为vaddps ymm1, [rsi+rax]，甚至替换为vmovaps ymm1, [rsi+rax](！)，我也可以重现此问题。后者证明问题不是由于依赖关系而是由于解码或执行的怪癖。核心没有过载-它具有2个向量读取，1个向量写入，一个标量ALU op和一个分支。也许uop融合不会发生。有趣的是，但此处可能不相关的是，预测采用的分支占用1-2 CC，而预测未采用的分支占用0.5-1 CC。
@IwillnotexistIdonotexist，是的，我认为宏融合没有发生。那可以解释为什么我要获得大约64个字节/周期而不是96个字节/周期。否则，我希望效率在66％到100％之间。
@IwillnotexistIdonotexist @Mysticial，对vaddps的观察不错。这就是为什么我在这里将stackrollflow.com/questions/25774190/展开八次的原因。基本相同，只是使用加法而不是fma。您也可以尝试使用vmulps，但不会有所不同：vfmaddxxxps，vmulps或vaddps的性能均相同。我的意思是，每个周期获得的字节数少于64个字节，而不是每个周期96个字节。
@Zboson：恕我直言，宏融合正在工作。简单测试(对指令进行重新排序，以便在add和jne之间存在一些东西)显示出明显的性能下降。
@EvgenyKluev，观察得很好。我实际上已经观察到了这一点，但没有得出正确的结论。
@EvgenyKluev，效率低于66％的事实告诉我带宽从未超过64个字节/周期。这意味着它要么每个周期读取32 * 2个字节，要么每个周期读取32个字节并写入32个字节。它永远不会在同一周期中读取32 * 2字节并写入32字节。否则，我认为效率会超过66％。但是，通过展开可以得到90％以上的数据，这表明Haswell显然是在同一周期中读取32 * 2字节并写入32字节的电缆。
我注意到在短循环中运行"三合一"代码(1)好像分支错误预测的代价很高，并且(2)在不同的内存访问模式下显示出非常不同的性能，因此[off]几乎具有理想的性能(但没用) ，而[r+r]要慢得多。我没有所有解释，但是知道这些事实可以进行一些优化：最佳数组大小约为16KB(对于3个数组，这略微超出L1)，最佳访问模式为[r+off]。此代码的效率约为75％(如果未展开的话)。与OP中一样编译它，并与ld链接。
@EvgenyKluev，我对[off]和[r+r]观察到相同的内容。我尝试将[r+r]与add一起展开，但没有跳转，但从未中断66％。使用[r+offset]只能得到高于66％的效果(但是使用[base+mult*index+offset]则不能得到)。这很奇怪，因为[r+offset]比[r+r]产生的指令更长(7字节vs. 6字节)。并感谢您的代码。通过阅读，我学到了很多东西(对x86汇编和NASM来说是新知识)。虐待尽快尝试。
@EvgenyKluev，随时写一个答案。我会赞成你现在所拥有的。
@Mysticial，根据此消息(realworldtech.com/haswell-cpu/2)，在Haswell中有一个复杂的解码器和三个简单的解码器。复杂的循环每个周期可以吐出4个融合的uops，而简单的循环仅吐出1个。但是，此循环应该从uop解码队列中获取，因为它是如此之小。
@IwillnotexistIdonotexist，我现在的理解是，由于循环适合μop缓存，因此我们无需担心这些解码器。此外，解码器每个周期只能处理16个字节的指令提取，而μop高速缓存可以每个周期处理32个字节(您可以在图中看到)。因此，在这种情况下，我认为Agners关于四个解码器中的最后一个的声明不适用。如果您阅读了Agners优化装配手册中的12.9节" Sandy Bridge上的相同示例"，我认为它可以解释这一点(或者至少就是我从中读到的内容)。
@EvgenyKluev，我终于运行了您的代码。我做了rcx, 2539062 ; 1.3GHz -> 1 secclock。这将在1.375秒内完成。大约占73％。我喜欢您的解决方案跳过C。您如何安排时间？给定可执行文件evgengy，我做了time .evgengy。现在，我需要一些时间来进一步诊断您的代码。
@EvgenyKluev，您的代码中的[off]是什么意思？如果我只是读取和写入相同的偏移量，则需要5.6秒(我认为这是由于写入停顿后的读取)。
我还使用time实用程序来衡量执行时间。仅在计算逆数之前，我减去0.05秒。用于load + warmup + etc。要获得要减去的精确值，只需使用空循环(仅add / jne)运行程序。 [off]是指偏移量。绝对我写了一些[off]，但随后从[off+64]读取以避免停顿。顺便说一句，它有可能改善展开方法，并使其性能提高2..3％。如果展开2 * 2次，此代码给出88％；如果展开4 * 2次，则给出93％。
@EvgenyKluev，知道了，我知道它被抵消了，但没有想到尝试在写入上尝试[offset+64]。现在我明白你的意思了。虽然我能做到90%。听起来您进展良好。我并不完全反对某些展开。我只想了解为什么这样做是必要的，如果有可能做得好于93％左右。
@ EvgenyKluev，BTW，矩阵多重处理器上的Intel MKL在AVX上使用较大的n可获得97％的效率。但是，上一次我在FMA的haswell上进行尝试时，结果不到90％。我认为这意味着即使是英特尔也在努力提高Haswell的效率。在其他我做过的带宽测试中(例如sum*=x[i])，我只能得到约70％的带宽。
@EvgenyKluev，我尝试了您的4 * 2展开代码。它得到95％(从时间中减去0.05)。干得好！
看来这种测量方法并不精确。至少对于接近100％的表演。最好将常数乘以10，而忽略预热时间。这样我得到的不是95％或93％，而是90％。
@EvgenyKluev，是的，我怀疑。我不会将其用于精确度，但是会获得进步。但是将您的代码放入我的C代码应该很容易。那应该更精确。只需忽略x，y，z寄存器(rdi，rsi，rdx)，然后使用重复寄存器rdc。
@Mysticial大喊大叫-问题已解决。神秘，您以一种奇怪的方式-商店顽固地拒绝使用Port 7。
@Mysticial如果您两个对32x展开循环的分析感兴趣，请参见下面的内容。请注意，商店现在如何到达端口7，联合吞吐量吞吐量瓶颈现在不少于6个。
@Mysticial另外，我尝试更改展开版本以具有其他展开因素。在1x时，循环需要1.75 CC，存储被拆分，瓶颈是前端。在2倍的循环中，耗时为2.5 CC，商店没有分配，瓶颈仍然是前端。在4x，8x，16x及更高的速度下，循环需要4/8/16 CC，存储不会拆分，瓶颈是前端，端口2和3s AGU和数据加载器，端口4和端口7。因数因此为4。
@IwillnotexistIdonotexist那真棒。我猜仍然如此，它有助于为处理器提供足够的"空间"以达到稳态。
@ IwillnotexistIdonotexist，unroll16可能不是名称的好选择。它应该已经展开。这是有历史意义的，因为在开始使用NASM宏之前，我一直在手动展开(汇编很棒)。就在我发布之前，我必须尝试将32解开并忘记切换回去(SSE和AVX版本仍然是16)。
@IwillnotexistIdonotexist，"前端"是什么意思？
@IwillnotexistIdonotexist，我认为展开的效率是eff = (3*unroll)(3*unroll+4)。因此，展开16次时，效率应为92％。八次应为约86％。 Evgeny在stackoverflow.com/questions/25774190/上获得了87％的八次解开??。因此，我不太确定我的公式是正确的，但似乎正确。
@Z玻色子Im指的是IACA工具的输出，但"前端"表示向执行单元(即它们前面)提供的所有内容。前端是瓶颈，这意味着uop缓存或重新排序缓冲区无法使执行端口繁忙。
@IwillnotexistIdonotexist，啊..现在我看到了这个"前端"的来源。 IACA报告"吞吐量瓶颈：FrontEnd，PORT2_AGU，PORT3_AGU"。它在一行瓶颈中为您提供了摘要。凉！我将不得不尝试IACA。
@Zboson当我由于您的悬赏而第一次注意到您的问题时，我知道这个工具会很有用(我以前使用过)，但是我忘记了它的名字！我花了两天时间来记忆我。无论如何，要使IACA与nasm一起使用，您只需要在循环的第一条指令之前放置一个特定的魔术字节序列，并在向后分支之后紧接着放置另一个魔术字节序列。该程序将不再运行，但是IACA会选择并分析它。
@IwillnotexistIdonotexist，我有一个愚蠢的问题。我正在尝试IACA。我可以将标记放入内部函数中并获得所需的结果，但我不确定将NASM代码放在何处。当我将它们放在NASM函数triad_fma_asm_repeat之间时，它只会看到函数调用的说明。你是怎么做的？
@Zboson我在最内层循环的第一条指令之前和条件分支向后的相同位置后立即添加了开始标记。 IACA的局限性在于它只能分析最内部的循环(而且Im甚至不确定它是否会处理其中的分支)，但这通常是人们感兴趣的。
@Zboson您可以在NASM中通过在相关位置说db 0Dh, 0Fh, ......来完成此操作。
@IwillnotexistIdonotexist，哦，我明白了。您使用了标题中的指令，并将其直接插入到NASM代码中。现在工作了！
是的;; START_MARKER mov ebx，111 db 0x64，0x67，0x90; END_MARKER mov ebx，222 db 0x64，0x67，0x90
@IwillnotexistIdonotexist，有两个问题。存储库不将端口7与[r+r]一起使用，但是即使存储库为[r+offset]，负载也不会与[r+r]进行微操作融合。每个周期不展开即可获得4 microps的唯一解决方案是使用带有[r+offset]的静态数组。
@Zboson您是否像现在所做的那样尝试对kicks [r+r]进行加载，但是仅将目标数组设为静态？另外，您现在实际维持5.125 uops / CC：164/32 = 5.125。
@IwillnotexistIdonotexist，是的，我尝试了[r+r]的加载和仅用于[r+offset]商店的静态数组。 fma和负载仍无法融合。因此，即使在修复商店后，仍然存在将FMA与加载融合的问题。因此，我认为唯一的解决方案是[r+offset]用于装载和存储。虐待尝试今天调查。
为什么第一个代码段的原型错误？它甚至不编译，返回类型是void而不是float
@cat，编译正常。也许它发出警告。您是正确的，它应该是无效的。

IACA分析

使用IACA(英特尔架构代码分析器)表明，确实发生了宏运算融合，而这并不是问题所在。是Mysticial谁是正确的：问题是商店根本没有使用Port 7。

好的。

IACA报告以下内容：

好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Intel(R) Architecture Code Analyzer Version - 2.1
Analyzed File - ../../../tests_fma
Binary Format - 64Bit
Architecture - HSW
Analysis Type - Throughput

Throughput Analysis Report
--------------------------
Block Throughput: 1.55 Cycles Throughput Bottleneck: FrontEnd, PORT2_AGU, PORT3_AGU

Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
| Port | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 |
---------------------------------------------------------------------------------------
| Cycles | 0.5 0.0 | 0.5 | 1.5 1.0 | 1.5 1.0 | 1.0 | 0.0 | 1.0 | 0.0 |
---------------------------------------------------------------------------------------

N - port number or number of cycles resource conflict caused delay, DV - Divider pipe (on port 0)
D - Data fetch pipe (on ports 2 and 3), CP - on a critical path
F - Macro Fusion with the previous instruction occurred
* - instruction micro-ops not bound to a port
^ - Micro Fusion happened
# - ESP Tracking sync uop was issued
@ - SSE instruction followed an AVX256 instruction, dozens of cycles penalty is expected
! - instruction not supported, was not accounted in Analysis

| Num Of | Ports pressure in cycles | |
| Uops | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 | |
---------------------------------------------------------------------------------
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [rdi+rax*1]
| 2 | 0.5 | 0.5 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [rsi+rax*1]
| 2 | | | 0.5 | 0.5 | 1.0 | | | | CP | vmovaps ymmword ptr [rdx+rax*1], ymm1
| 1 | | | | | | | 1.0 | | | add rax, 0x20
| 0F | | | | | | | | | | jnz 0xffffffffffffffec
Total Num Of Uops: 6

特别是，报告的周期(1.5)中的块吞吐量非常好，效率为66％。

好的。

英特尔员工在Tue, 03/11/2014 - 23:20上的回信中，在IACA自己的网站上发布了关于Tue, 03/11/2014 - 12:39上这种现象的帖子：

好的。

Port7 AGU can only work on stores with simple memory address (no index register). This is why the above analysis doesn't show port7 utilization.

Ok.

这可以确定为什么不使用Port 7。

好的。

现在，将上面的内容与32x展开循环进行对比(事实证明unroll16 shoudl实际上被称为unroll32)：

好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
Intel(R) Architecture Code Analyzer Version - 2.1
Analyzed File - ../../../tests_fma
Binary Format - 64Bit
Architecture - HSW
Analysis Type - Throughput

Throughput Analysis Report
--------------------------
Block Throughput: 32.00 Cycles Throughput Bottleneck: PORT2_AGU, Port2_DATA, PORT3_AGU, Port3_DATA, Port4, Port7

Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
| Port | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 |
---------------------------------------------------------------------------------------
| Cycles | 16.0 0.0 | 16.0 | 32.0 32.0 | 32.0 32.0 | 32.0 | 2.0 | 2.0 | 32.0 |
---------------------------------------------------------------------------------------

N - port number or number of cycles resource conflict caused delay, DV - Divider pipe (on port 0)
D - Data fetch pipe (on ports 2 and 3), CP - on a critical path
F - Macro Fusion with the previous instruction occurred
* - instruction micro-ops not bound to a port
^ - Micro Fusion happened
# - ESP Tracking sync uop was issued
@ - SSE instruction followed an AVX256 instruction, dozens of cycles penalty is expected
! - instruction not supported, was not accounted in Analysis

| Num Of | Ports pressure in cycles | |
| Uops | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 | |
---------------------------------------------------------------------------------
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x20]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x20]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x20], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x40]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x40]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x40], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x60]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x60]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x60], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x80]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x80]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x80], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0xa0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0xa0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0xa0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0xc0]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0xc0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0xc0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0xe0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0xe0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0xe0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x100]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x100]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x100], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x120]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x120]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x120], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x140]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x140]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x140], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x160]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x160]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x160], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x180]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x180]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x180], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x1a0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x1a0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x1a0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x1c0]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x1c0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x1c0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x1e0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x1e0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x1e0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x200]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x200]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x200], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x220]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x220]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x220], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x240]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x240]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x240], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x260]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x260]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x260], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x280]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x280]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x280], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x2a0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x2a0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x2a0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x2c0]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x2c0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x2c0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x2e0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x2e0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x2e0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x300]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x300]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x300], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x320]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x320]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x320], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x340]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x340]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x340], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x360]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x360]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x360], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x380]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x380]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x380], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x3a0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x3a0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x3a0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x3c0]
| 2^ | 1.0 | | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x3c0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x3c0], ymm1
| 1 | | | 1.0 1.0 | | | | | | CP | vmovaps ymm1, ymmword ptr [r9+0x3e0]
| 2^ | | 1.0 | | 1.0 1.0 | | | | | CP | vfmadd231ps ymm1, ymm2, ymmword ptr [r10+0x3e0]
| 2^ | | | | | 1.0 | | | 1.0 | CP | vmovaps ymmword ptr [r11+0x3e0], ymm1
| 1 | | | | | | 1.0 | | | | add r9, 0x400
| 1 | | | | | | | 1.0 | | | add r10, 0x400
| 1 | | | | | | 1.0 | | | | add r11, 0x400
| 1 | | | | | | | 1.0 | | | cmp r9, rcx
| 0F | | | | | | | | | | jnz 0xfffffffffffffcaf
Total Num Of Uops: 164

我们在这里看到微融合，并正确安排了到端口7的存储调度。

好的。

手动分析(请参见上面的编辑)

现在，我可以回答您的第二个问题：是否可以在不展开的情况下实现，如果可以，该怎么办？答案是不。

好的。

我为左右实验在数组左右分别填充了x，y和z数组，并将内部循环更改为以下内容：

好的。

1
2
3
4
5
6
.L2:
vmovaps ymm1, [rdi+rax] ; 1L
vmovaps ymm0, [rsi+rax] ; 2L
vmovaps [rdx+rax], ymm2 ; S1
add rax, 32 ; ADD
jne .L2 ; JMP

这有意不使用FMA(仅加载和存储)，并且所有加载/存储指令都没有依赖性，因为因此，无论有什么危险，都可以防止将它们发布到任何执行端口中。

好的。

然后，我测试了第一个和第二个加载(1L和2L)，存储(S1)和加(A)的每个单个排列，同时最后保留了条件跳转(J) ，对于每一种，我都测试了x，y和z的偏移量每种可能组合的0或-32字节(以纠正在r+r之一之前重新排列add rax, 32的事实索引会导致加载或存储定位到错误的地址)。循环对齐为32个字节。这些测试在Linux上通过echo '0' > /sys/devices/system/cpu/cpufreq/boost禁用了TurboBoost的2.4GHz i7-4700MQ上运行，并且频率常数使用2.4。以下是效率结果(最多24个)：

好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Cases: 0 1 2 3 4 5 6 7
L1 L2 S L1 L2 S L1 L2 S L1 L2 S L1 L2 S L1 L2 S L1 L2 S L1 L2 S
-0 -0 -0 -0 -0 -32 -0 -32 -0 -0 -32 -32 -32 -0 -0 -32 -0 -32 -32 -32 -0 -32 -32 -32
________________________________________________________________________________________________
12SAJ: 65.34% 65.34% 49.63% 65.07% 49.70% 65.05% 49.22% 65.07%
12ASJ: 48.59% 64.48% 48.74% 49.69% 48.75% 49.69% 48.99% 48.60%
1A2SJ: 49.69% 64.77% 48.67% 64.06% 49.69% 49.69% 48.94% 49.69%
1AS2J: 48.61% 64.66% 48.73% 49.71% 48.77% 49.69% 49.05% 48.74%
1S2AJ: 49.66% 65.13% 49.49% 49.66% 48.96% 64.82% 49.02% 49.66%
1SA2J: 64.44% 64.69% 49.69% 64.34% 49.69% 64.41% 48.75% 64.14%
21SAJ: 65.33%* 65.34% 49.70% 65.06% 49.62% 65.07% 49.22% 65.04%
21ASJ: Hypothetically =12ASJ
2A1SJ: Hypothetically =1A2SJ
2AS1J: Hypothetically =1AS2J
2S1AJ: Hypothetically =1S2AJ
2SA1J: Hypothetically =1SA2J
S21AJ: 48.91% 65.19% 49.04% 49.72% 49.12% 49.63% 49.21% 48.95%
S2A1J: Hypothetically =S1A2J
SA21J: Hypothetically =SA12J
SA12J: 64.69% 64.93% 49.70% 64.66% 49.69% 64.27% 48.71% 64.56%
S12AJ: 48.90% 65.20% 49.12% 49.63% 49.03% 49.70% 49.21%* 48.94%
S1A2J: 49.69% 64.74% 48.65% 64.48% 49.43% 49.69% 48.66% 49.69%
A2S1J: Hypothetically =A1S2J
A21SJ: Hypothetically =A12SJ
A12SJ: 64.62% 64.45% 49.69% 64.57% 49.69% 64.45% 48.58% 63.99%
A1S2J: 49.72% 64.69% 49.72% 49.72% 48.67% 64.46% 48.95% 49.72%
AS21J: Hypothetically =AS21J
AS12J: 48.71% 64.53% 48.76% 49.69% 48.76% 49.74% 48.93% 48.69%

我们可以从表中注意到一些事情：

好的。

结果达到几个平稳状态，但只有两个主要结果：略低于50％和大约65％。

L1和L2可以在彼此之间自由置换，而不会影响结果。

将访问偏移-32字节可以改变效率。

我们感兴趣的模式(加载1，加载2，存储1和跳转，并在它们周围的任意位置加上-32正确应用的偏移量)都相同，并且都位于较高的高原地区：

12SAJ情况0(未应用偏移)，效率为65.34％(最高)

12ASJ情况1(S-32)，效率64.48％

1A2SJ情况3(2L-32，S-32)，效率64.06％

A12SJ情况7(1L-32，2L-32，S-32)，效率为63.99％

好的。

对于每个排列，总是存在至少一个"情况"，从而可以在更高的效率平台上执行。特别是案例1(其中S-32)似乎可以保证这一点。

案例2、4和6保证了在较低的高原上执行。它们的共同点是，其中一个或两个负载偏移了-32，而商店却没有。

对于情况0、3、5和7，取决于排列。

好的。

从那里我们至少可以得出一些结论：

好的。

执行端口2和3确实不在乎它们生成和加载哪个加载地址。

add和jmp的宏操作融合似乎不受指令的任何排列影响(特别是在情况1偏移的情况下)，使我相信@Evgeny Kluev的结论是错误的：add与jne似乎不影响它们的融合。我现在可以肯定地说，Haswell ROB可以正确处理此问题。

Evgeny看到的结果(在情况0中，从12SAJ效率为65％转换为效率为49％的其他变量)仅仅是由于从中加载和存储的地址的值，而不是由于内核的无效宏融合add和branch。

此外，由于平均循环时间为1.5 CC，因此必须至少在某些时间进行宏运算融合。如果没有发生宏视融合，则这将是最低2CC。

好的。

在未展开的循环中测试了指令的所有有效和无效排列之后，没有发现高于65.34％的内容了。这凭经验以"否"回答了是否有可能在不展开的情况下使用全部带宽的问题。

好的。

我将假设几种可能的解释：

好的。

由于地址相对于彼此的值，我们看到了一些奇怪的变态。

如果是这样，那么将存在一组偏移量x，y和z，这些偏移量将允许最大吞吐量。我的快速随机测试似乎不支持这一点。

好的。

我们看到循环以两步模式运行；循环迭代以一个时钟周期交替运行，然后是两个时钟周期。

好的。

这可能是宏运算融合受到解码器的影响。从Agner Fog：

好的。

不能在Sandy Bridge和Ivy Bridge处理器的四个解码器中的最后一个中解码可熔的算术/逻辑指令。我还没有测试过这是否也适用于Haswell。

好的。

或者，每隔一个时钟周期向"错误"端口发出一条指令，从而在一个额外的时钟周期内阻止下一次迭代。这种情况将在下一个时钟周期内自动纠正，但仍会保持振荡。

如果有人可以访问英特尔性能计数器，则应查看事件UOPS_EXECUTED_PORT.PORT_[0-7]。如果没有发生振荡，则在相关的时间段内，所有使用的端口都将被固定。否则，如果发生振荡，将有50％的分裂。尤其重要的是查看Mystical指出的端口(0、1、6和7)。

好的。

好的。

好的。

这是我认为没有发生的事情：

好的。

我不认为融合的算术+分支uop会通过转到端口0来阻止执行，因为预测采用的分支仅发送到端口6(请参见Haswell -> Control transfer instructions下的Agner Fog的指令表)。经过上面循环的几次迭代之后，分支预测器将得知该分支是一个循环，并且始终按所采用的那样进行预测。

好的。

我相信这是英特尔性能计数器可以解决的问题。

好的。

好。

相关讨论

很好的答案(+1)。并且很好地观察了移动add时的熔断。我想这就是为什么我犹豫要下结论。您对[r+r]的结论是正确的。但是，Evgeny声称使用静态数组和[绝对地址+索引]可以打破66％的障碍而不会展开。如果要访问性能计数器，可以使用Agner Fogs测试程序。它有自己的Linux和Windows设备驱动程序，可以很好地完成此操作。我应该用这个。

@Zboson现在查看寻址模式。获得一些成功：使用额外的寄存器和add并为存储执行[r]时，我可以达到约70％。

太好了，我期待看到您的结果。奇怪的是[r+r]不能突破66％的壁垒。

测试中rdx和其他基址寄存器(rsi, rdi)有什么区别？如果它是4096的倍数，是否可以通过错误共享来解释接近49％的所有结果？ (有关详细信息，请参见" L1内存带宽：效率下降50％...")。还应注意，宏融合指令必须为adjacent in the instruction stream(请参阅《英特尔优化》手册的3.4.2.2节，也在Agners手册中提到)。

@EvgenyKluev，我了解您关于保持宏融合指令相邻的观点。但是，阿格纳(Agner)写道"程序员应将任何可融合的算术指令保持在一起"，但他没有写"必须保持"。因此，我认为这也许不是必需条件，但使融合的可能性更大。让我查看一下英特尔手册。

@EvgenyKluev，我在英特尔手册中发现的所有内容是"第二条指令(与指令流相邻)应该是条件分支。"我想这意味着它们必须相邻。

@EvgenyKluev，他的12ASJ案例1(从0开始)怎么样，它在存储和跳转之间移动加法，仍然得到65％。因此，这意味着融合不会发生(这也可能意味着融合从未发生)。我同意您的观点，即50％的下降可能是由于错误分享造成的。

@Zboson：只是两个简单的测试。将寻址模式更改为[offset]并加长循环，以避免过多的错误预测。效率约为95％。如果您认为从未发生过定影，则无法解释。现在交换add和最后一个vmovaps。效率降至?81％。这里显然没有融合。

@EvgenyKluev，好吧，这很有道理。今晚会尝试测试您的代码。您要发布答案吗？

@Zboson：尚未决定。我希望在性能计数器的帮助下找到一些东西。或者(有些运气)您的问题吸引了知道确切答案的人的注意。

@EvgenyKluev @Zboson的确，在案例0中，rdx，rdi和rsi都被8192抵消了。我确实认为50％的平稳期正是您提到的那个问题的现象。但是，通过尝试比0或-32更多的偏移量，Ive无法将效率提高到66％以上。

@EvgenyKluev @Zboson我认为融合至少部分没有受到影响的原因是，如果不这样做，则循环时间将最少为2个周期。但是，对于所有情况(不只是***AJ)，情况1的效率为65％，循环时间为1.5个周期，这意味着融合必须至少发生一半的时间。

@EvgenyKluev是否知道每个周期可以使用一个寄存器多少次？ rax当前被读取4次，每次迭代写入1次，对于要占用1 CC的循环，它的使用非常繁琐。也许Haswell无法将加法的结果立即转发到这么多地方？

很好的主意！我从未听说过这样的限制。但是测试显示，在一条指令中将rax替换为其他寄存器后，会有一些改进。

@ IwillnotexistIdonotexist，SB之前的处理器中的"寄存器读取停顿"存在问题。例如，请参阅此处理器的Agners Pentium M示例。但是，此问题在SB / IB上消失了。也许它回来了。实际上，Agner在奔腾M上获得此功能的最大吞吐量的方式是通过执行12ASJ来完成的，方法是将添加位置移到存储区之前，并减去存储区的偏移量16(SSE)。我在Haswell上尝试了此方法，但获得了与您相同的结果，即从未超过66％。

再次努力！因此，端口2和3上的1.5是应该使用端口7在端口2和3之间分配的存储。

@Zboson我完全不知道为什么当端口7上有一个专用于它的端口时，前端为什么会在商店的端口2和3之间进行分配。我想这完全属于"执行的怪癖"。

据我所知，展开的版本仍需要选择端口7才能获得完整带宽。有趣的是，当不使用添加和跳转时，它会成功完成此任务。看到展开案例的计数器会很有趣。我从中学到的最重要的教训是停止哲学思考，而去看看柜台。

@Zboson我将尽快在展开的循环上运行IACA。只需要回到我的电脑。

还有另一种解释IACA Analysis的方法：其他一些原因会导致性能下降到66％以下，因此不需要端口7，因此为了节能，将其完全关闭。该端口中的正零支持此版本。提到的原因之一是非常昂贵的分支错误预测，因为长等待时间指令+相对较短的循环。其他仍然未知。

@EvgenyKluev但这是一个循环；最多会被两次错误地预测。可能在开始时(第一次遇到分支向后)一次，在结束时(当循环中断时)一次。在所有其他情况下，分支预测器将正常运行，并了解到该分支具有所谓的"循环行为"。诚然，您的建议是完全可能的，但是总体上可以很好地预测这种循环。

@EvgenyKluev也是关于节能的主题，目前处理器在将FMA发送到端口0和端口1之间交替进行。如果仅在一个端口或另一个端口上执行FMA，它将节省更多功率，因为??它可以控制另一个端口。而且我们知道端口0和1各自的吞吐量为1 FMA / CC，因此调度程序没有理由不一直将FMA发行到同一端口。

最有可能该循环仅被错误地预测了一次-最后。 (我认为循环的开始是正确预测的)。但是，这种单一的错误预测非常昂贵：15..20个时钟的最小错误预测损失(根据Agner Fog)。循环需要256个时钟来执行所有指令(对于8KB阵列)，因此最佳性能应约为256 /(256 + 15)= 94％。可能更少，因为指令等待时间较长。不知道为什么它不能关闭FMA之一。为端口7安排的0条指令仍然看起来像节能。我无法想象调度程序会"错误地"执行它。

@EvgenyKluev好了，我们现在知道发生了什么(使用Intel自己的工具)，但是如果没有Intel员工窥视这里，为什么我们不知道为什么？

总的microps是未融合的microps(但是宏融合仍然算作一个)。因此总数为(1+2+2)*32+4=164。但是，时钟周期数为(1+1+1)*32+4=100。因此，最佳效率是96100=96%展开32次。

"为什么不使用端口7的原因"很容易回答：端口7只能处理"简单的" AGU操作(基数+立即偏移量，IIRC)。它不能执行基址+寄存器偏移量。您可以通过使用存储地址作为加载操作数的偏移量来解决此问题。

@StephenCanon，哇..."它不能做基址和寄存器偏移量"，我希望有人早点说过！！！你有这个来源吗？您的确切含义是"可以通过使用存储地址作为加载操作数的偏移量来解决此问题"？

@StephenCanon现在，这将解释为什么我通过在r9中为存储维护一个单独的指针，并使其与加法并行增加lea r9, [r9+32]来在滚动循环中获得大约7％的改善。您从哪里了解有关Port 7 AGU的限制的？

@IwillnotexistIdonotexist，英特尔的优化手册在端口7上使用了表达式Simple_AGU。到目前为止，这就是我发现的所有内容。我仍在尝试查找Simple_AGU的定义。

@Zboson He的含义是，由于商店必须使用的Port 7 AGU比Port 2和3 AGU更原始，因此必须对代码进行优化。存储地址具有最简单的表达式([r+offset])，而加载地址基于存储地址(r+r*1+offset)。 IOW，而不是对所有访问使用r+r，而是设计指针s.t。存储单元仅具有r+offset特权

@IwillnotexistIdonotexist，我明白。我的意思是，除了使用[absolute 32-bit address + r]的静态数组之外，我不知道如何使用我的代码执行此操作。然后将r递增32。如果使用[r+r]进行装载，而使用[r+offset]进行存储，则需要另一条指令，而这不能用4个周期完成。认为这样做可能比66％更好。

@Zboson实际上，根据您自己安排的问题，端口1和5中都有空间，其中的任意一个(但特别是5个)都可以像add或lea一样进行算术运算(请参阅上面我的评论作为回应) (斯蒂芬)，这两种方法都能够以较小的常量递增寄存器。滚动循环中只有足够的空间，展开会增加更多空间。

@IwillnotexistIdonotexist，有可用的端口，但没有更多的microps。另一个添加将其推至五个。那要好于六个，但不胜于四个(这听起来像是Monte Python草图)。因此，充其量，您无需展开即可获得80％的效率。

@Zboson我相信这是展开的地方；在4倍以上时，端口5中有足够的时隙，可以发生展开循环中的所有指针增量。

@IwillnotexistIdonotexist，奇怪的是，Evgeny使用[offset + r]使用静态数组，但仍然没有获得很高的效率。我认为这将使用端口7并获得90％以上的效率而不会展开。

Iaca表示这应该可行(展开4倍时效率为88％)；它受前端的限制。不幸的是，我没有HSW可以方便地进行测试。

@IwillnotexistIdonotexist，我没有使用vmovaps [r9], ymm1; lea r9, [r9+32]进行改进。实际上，其效率仅为52％。但是，使用静态数组进行写入vmovaps [dst_end+rax], ymm1确实得到了改进。效率约为68％。

@IwillnotexistIdonotexist，我使用商店地址作为展开时负载中的索引，它肯定更好。我现在有94％的人解开256次。展开四次可获得约77％的收益。

@Zboson有趣；我猜想IACA在进行分析时只考虑了完美的案例(没有错误的共享，延迟或其他问题)。 IACA已经以4倍的展开速度预测了完美的性能。

但是不展开只会得到56％。我认为是因为我必须要做一个add，cmp和jcc，而不仅仅是add和jcc。无需展开代码即可改进代码的唯一方法是为商店使用静态数组，但无论如何它仅占68％。

opps ...完全展开是一种特殊情况。我不需要任何添加/ CPS。但是无论如何，我的集成时间都很短，所以效率的误差只有几个百分点：92％似乎是平均可以实现的最好水平。

@Zboson我知道这会让你发笑，但是... 6个月前，在IACA自己的网站上注意到，询问并回答了同样的问题，问题和答案！请参见Tue, 03112014 - 12:39上的注释。

@IwillnotexistIdonotexist，那真是令人毛骨悚然！您完全正确！在" Port7 AGU只能在具有简单内存地址(无索引寄存器)的存储区上工作"之后立即查看注释。

@IwillnotexistIdonotexist，下一个注释是"通过显式(快速)许可在端口1或5上生成基本寄存器，并在存储中使用该寄存器显着提高了速度，我想知道为什么编译器在使用-xHost时没有想到这一点现在，我什至在一个简单的加载/存储基准测试中获得了?94B / c。"我不确定他到底做了什么。

@IwillnotexistIdonotexist，我在这里总结了我们的发现，以补充我的问题。让我知道你的想法。

@Zboson酷！看起来挺好的。就我而言，我想知道是否应该对IACA进行问答并在此处创建其标签。

@IwillnotexistIdonotexist，我不确定"在IACA上进行问答并在此处创建其标签"的确切含义，但这对我来说是个好主意。从我的角度来看，IACA是金牌，非常值得我花500代表。

@IwillnotexistIdonotexist，哈哈，那就偷偷摸摸！但是我很高兴你做到了。您是否意识到自己现在处于本周最高积分的首页上？点击用户并按周排名。

太好了，现在写一篇解释如何使用轻量级采样探查器来找出IACA =中要关注的循环的文章。

关于各种uop限制：如果192条目ROB(重排序缓冲区)中有适当的uops，并且满足了所有依赖关系，则可以在一个周期内在所有8个端口上执行uop。但是每个周期可以进入ROB的前端限制为4(未融合)微码。即使uops来自微小循环缓冲区或?1000条目解码的uop缓冲区，这也适用。每个循环还有4个(融合)微码的后端限制。结果，每个周期的持续吞吐率不能超过4 oups。展开循环有助于确定它是否处于这些限制之下。

由于错误而错过了编辑窗口：解码的指令缓冲区存储了融合的uops，因此来自它的所有内容都应计入融合域中。此处具有每个周期限制的图表：pc.watch.impress.co.jp/video/pcw/docs/601/161/p21.pdf