我目前正在优化一段数学运算代码,在该代码上循环遍历指针存储并将结果保存到位。
我注意到在每次分配时,编译器都会发出一条存储指令,如下所示(vmovaps
要注意):
114 [1] top_data_c[pc] += w1 * bottom_data_hwc[o1 + pc];
0x55555558bf70 <+ 2624> c4 c1 78 10 0c 02 vmovups (%r10,%rax,1),%xmm1
0x55555558bf76 <+ 2630> 48 83 c1 01 add $0x1,%rcx
0x55555558bf7a <+ 2634> c4 c3 75 18 4c 02 10 01 vinsertf128 $0x1,0x10(%r10,%rax,1),%ymm1,%ymm1
0x55555558bf82 <+ 2642> c4 c2 25 a8 0c 04 vfmadd213ps (%r12,%rax,1),%ymm11,%ymm1
0x55555558bf88 <+ 2648> c4 c1 7c 29 0c 04 vmovaps %ymm1,(%r12,%rax,1)
115 [1] top_data_c[pc] += w2 * bottom_data_hwc[o2 + pc];
0x55555558bf8e <+ 2654> c4 c1 78 10 04 01 vmovups (%r9,%rax,1),%xmm0
0x55555558bf94 <+ 2660> c4 c3 7d 18 44 01 10 01 vinsertf128 $0x1,0x10(%r9,%rax,1),%ymm0,%ymm0
0x55555558bf9c <+ 2668> c4 c2 7d b8 ca vfmadd231ps %ymm10,%ymm0,%ymm1
0x55555558bfa1 <+ 2673> c4 c1 7c 29 0c 04 vmovaps %ymm1,(%r12,%rax,1)
116 [1] top_data_c[pc] += w3 * bottom_data_hwc[o3 + pc];
0x55555558bfa7 <+ 2679> c4 c1 78 10 04 00 vmovups (%r8,%rax,1),%xmm0
0x55555558bfad <+ 2685> c4 c3 7d 18 44 00 10 01 vinsertf128 $0x1,0x10(%r8,%rax,1),%ymm0,%ymm0
0x55555558bfb5 <+ 2693> c4 c2 75 98 c1 vfmadd132ps %ymm9,%ymm1,%ymm0
0x55555558bfba <+ 2698> c4 c1 7c 29 04 04 vmovaps %ymm0,(%r12,%rax,1)
117 [1] top_data_c[pc] += w4 * bottom_data_hwc[o4 + pc];
0x55555558bfc0 <+ 2704> c5 f8 10 0c 07 vmovups (%rdi,%rax,1),%xmm1
0x55555558bfc5 <+ 2709> c4 e3 75 18 4c 07 10 01 vinsertf128 $0x1,0x10(%rdi,%rax,1),%ymm1,%ymm1
0x55555558bfcd <+ 2717> c4 c2 75 b8 c0 vfmadd231ps %ymm8,%ymm1,%ymm0
0x55555558bfd2 <+ 2722> c4 c1 7c 29 04 04 vmovaps %ymm0,(%r12,%rax,1)
0x55555558bfd8 <+ 2728> 48 83 c0 20 add $0x20,%rax
0x55555558bfdc <+ 2732> 48 39 4d c0 cmp %rcx,-0x40(%rbp)
0x55555558bfe0 <+ 2736> 77 8e ja 0x55555558bf70
但是,当我将指针更改为局部“堆栈数组”变量(即T top_data_c[1024]
)时,存储指令仅出现在循环的结尾:
114 [1] top_data_c[pc] += w1 * bottom_data_hwc[o1 + pc];
0x55555558bbe0 <+ 1712> c5 f8 10 0c 03 vmovups (%rbx,%rax,1),%xmm1
0x55555558bbe5 <+ 1717> 48 83 c1 01 add $0x1,%rcx
0x55555558bbe9 <+ 1721> c4 e3 75 18 4c 03 10 01 vinsertf128 $0x1,0x10(%rbx,%rax,1),%ymm1,%ymm1
0x55555558bbf1 <+ 1729> c4 c2 25 a8 0c 04 vfmadd213ps (%r12,%rax,1),%ymm11,%ymm1
0x55555558bbf7 <+ 1735> c5 fc 28 c1 vmovaps %ymm1,%ymm0
115 [1] top_data_c[pc] += w2 * bottom_data_hwc[o2 + pc];
0x55555558bbfb <+ 1739> c4 c1 78 10 0c 03 vmovups (%r11,%rax,1),%xmm1
0x55555558bc01 <+ 1745> c4 c3 75 18 4c 03 10 01 vinsertf128 $0x1,0x10(%r11,%rax,1),%ymm1,%ymm1
0x55555558bc09 <+ 1753> c4 c2 7d 98 ca vfmadd132ps %ymm10,%ymm0,%ymm1
116 [1] top_data_c[pc] += w3 * bottom_data_hwc[o3 + pc];
0x55555558bc0e <+ 1758> c4 c1 78 10 04 02 vmovups (%r10,%rax,1),%xmm0
0x55555558bc14 <+ 1764> c4 c3 7d 18 44 02 10 01 vinsertf128 $0x1,0x10(%r10,%rax,1),%ymm0,%ymm0
0x55555558bc1c <+ 1772> c4 e2 35 b8 c8 vfmadd231ps %ymm0,%ymm9,%ymm1
117 [1] top_data_c[pc] += w4 * bottom_data_hwc[o4 + pc];
0x55555558bc21 <+ 1777> c4 c1 78 10 04 01 vmovups (%r9,%rax,1),%xmm0
0x55555558bc27 <+ 1783> c4 c3 7d 18 44 01 10 01 vinsertf128 $0x1,0x10(%r9,%rax,1),%ymm0,%ymm0
0x55555558bc2f <+ 1791> c4 c2 75 98 c0 vfmadd132ps %ymm8,%ymm1,%ymm0
0x55555558bc34 <+ 1796> c4 c1 7c 29 04 04 vmovaps %ymm0,(%r12,%rax,1)
0x55555558bc3a <+ 1802> 48 83 c0 20 add $0x20,%rax
0x55555558bc3e <+ 1806> 48 3b 8d c8 fb ff ff cmp -0x438(%rbp),%rcx
0x55555558bc45 <+ 1813> 72 99 jb 0x55555558bbe0
出现了编译器由于线程不安全而使指针存储动作无法优化的情况。
在这样的实现中,声明来回堆栈数组或临时变量的复制看起来很脏,有没有办法使这种指针存储对编译器而言是线程安全的?当然,这种计算是完全线程安全的(它的工作原理与GPU非常相似)。
答案 0 :(得分:4)
除非您出于某种原因将top_data_c
指针声明为volatile
,否则编译器可以自由地假定对其写入的数据不进行任何外部(包括并发)修改,因此缺乏优化是不要怪罪于线程化(并且不能通过线程局部语义解决)。
这里真正的问题是别名-编译器 不能假设top_data_c[pc]
不在bottom_data_hwc
内部(它可能与bottom_data_hwc[o4 + pc]
相同,谁知道?),所以它必须去商店。在“堆栈数组”情况下缓解此问题的原因是(如果我没有记错的话)top_data_c
是数组而不是指针的事实(不是它在堆栈上还是在线程本地)
简短介绍严格的别名规则:编译器可以假定指向不兼容类型(例如int
和double
)的指针不能指向同一位置。如果您在void foo(int* x, double* y)
内部,则在严格的别名规则下,写入x
不会更改您从y
读取的内容(反之亦然),因此编译器可以自由地重新排序或取消存储并根据需要在此函数内向x
和y
进行读取。
但是在void foo(double* x, double* y)
内部,此保证消失了。如果x == y
(或x == y + n
)对x
进行读写,则y
可能彼此交互,并且编译器别无选择,只能执行每个加载/商店。
您应该查看与restrict
相关的关键字,该关键字指示编译器“仅通过x
(及其副本) 访问x
在此功能中”。一些材料:
What does the restrict keyword mean in C++?
https://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
http://assemblyrequired.crashworks.org/load-hit-stores-and-the-__restrict-keyword/