04.srt

1
00:00:00,542 --> 00:00:07,999
我们现在开始上课，嗯，首先今天的主题是编译器优化

2
00:00:07,999 --> 00:00:10,999
然后编译器是什么呢？

3
00:00:10,999 --> 00:00:16,684
众所周知，编译器就是从源代码生成汇编语言，

4
00:00:16,708 --> 00:00:27,999
所以这次要从汇编语言的角度来理解编译器是怎么优化的，以及我们如何用好它

5
00:00:27,999 --> 00:00:34,999
首先这是一个系列课，我们今天已经是第四讲了

6
00:00:34,999 --> 00:00:44,999
然后这次我们会基于GCC，然后还有64位x86架构，来具体讲讲

7
00:00:44,999 --> 00:00:55,724
然后第0章首先要讲解一下什么是汇编语言，就是首先是x86的64位架构，

8
00:00:55,748 --> 00:01:02,792
还有这些寄存器。寄存器呢，它又是在CPU里面的

9
00:01:02,792 --> 00:01:10,999
然后它的速度比内存快，如果读到寄存器里，然后再计算就比较高效

10
00:01:10,999 --> 00:01:19,999
所以x64它提供了这么多寄存器，其中白色的这些是32位模式下就有的

11
00:01:19,999 --> 00:01:27,487
而64位以后，不仅把原来32位的这几个扩充到64位，

12
00:01:27,511 --> 00:01:34,999
它还额外追加了8个寄存器，这样我们用起来就更方便了

13
00:01:34,999 --> 00:01:44,999
然后RIP是它的当前执行的这个代码的地址，嗯，也是扩充到64位

14
00:01:44,999 --> 00:01:56,999
然后还有这些MMX，还有YMM,XMM这些,这些都是那个用于存储浮点数的寄存器

15
00:01:56,999 --> 00:02:03,754
它们能够,就是一个,就是这个不是一个有128位宽嘛，

16
00:02:03,778 --> 00:02:15,999
然后float 它不是有32位宽嘛，所以这里面可以塞得下四个float
或者塞两个double

17
00:02:15,999 --> 00:02:24,999
然后他们在运算加法的时候就可以两个double一起来算这样它效率就更高了,为什么

18
00:02:24,999 --> 00:02:28,209
为什么说浮点数用的是这个呢？

19
00:02:28,209 --> 00:02:35,198
因为浮点数就是我们高性能计算中经常用到浮点数，

20
00:02:35,222 --> 00:02:43,125
所以就干脆把他们认为是那个，嗯你懂的，就是比较高效嘛

21
00:02:43,999 --> 00:02:59,999
明白吗？哦，对我得开一下弹幕，嗯，然后我这个就关掉了

22
00:03:02,292 --> 00:03:12,999
然后就是刚才说的32位，只有这八个寄存器，然后到64位以后又新增了八个寄存器

23
00:03:12,999 --> 00:03:23,999
可以看到这几个没有在命名强迫症了，它们直接用数字来编号，然后寄存器多有什么好处呢

24
00:03:23,999 --> 00:03:34,999
就是比如，你的局部变量有16个，那它们就都能够存进寄存器里，而不需要存到内存上

25
00:03:34,999 --> 00:03:43,999
这样编译器它就可以自由的把你的变量存到这个局部的这个

26
00:03:43,999 --> 00:03:50,999
就是说把你的局部变量变成一个寄存器，这样它读写就更快了

27
00:03:50,999 --> 00:03:56,999
所以说64位除了内存更大，它还有性能的优势

28
00:03:57,999 --> 00:04:08,999
然后就是说有刚刚不是看到就是32位叫eax，到64位变成rax，它们是什么关系呢？

29
00:04:08,999 --> 00:04:19,999
它们是共用前32位的关系，就是eax这个地方的值和rax的低32位是共用的

30
00:04:19,999 --> 00:04:30,709
同理还有16位的rax它和eax共用的低16位，然后ah是ax的高八位，然后al是低8位

31
00:04:30,709 --> 00:04:41,999
当然r开头的这些数字编号寄存器也有，他们是通过bwd然后没有来区别的，有问题吗？

32
00:04:42,999 --> 00:04:57,999
对，AVX它用的是zmm，AVX512 它是zmm，然后AVX用的呢是ymm，它是256位

33
00:04:57,999 --> 00:05:07,999
然后还有最普通的SSE，用的是xmm，它们只有那个128位

34
00:05:08,024 --> 00:05:25,858
然后就是我们说就是汇编语言大致分为两种，一种是英特尔模式的汇编，它写寄存器就直接写eax，

35
00:05:25,882 --> 00:05:35,024
然后它写操作数，就比如eax赋值给edx，就把edx写在前面，eax写后面

36
00:05:35,999 --> 00:05:42,999
然后用mov指令就把eax赋给edx，而AT&T汇编它

37
00:05:42,999 --> 00:05:53,500
恰恰相反，它读的那个数字写在前面的，写的那个数字写在后面的，也就是说这个是往右移动的

38
00:05:53,500 --> 00:06:00,292
而英特尔是往左移动的，包括它的立即数，也是用一个S符号

39
00:06:00,292 --> 00:06:10,999
然后它也是往右移的，嗯，然后jmp指令它还要以额外的乘法符号以及它的操作数长度，

40
00:06:10,999 --> 00:06:12,980
就是英特尔就直接mov，

41
00:06:13,004 --> 00:06:28,792
而我们这个AT&T它后面要加一个movl，代表是long
，也就是32位，而b呢就是八位，w呢就是16位

42
00:06:29,999 --> 00:06:33,999
然后他的这个访问地址呢也不一样

43
00:06:33,999 --> 00:06:42,458
这里英特尔是更直观的一个[]，然后这里写偏移量，而它是把偏移量写在()前面，

44
00:06:42,482 --> 00:06:50,417
然后后面来一个(%dx)代表它偏移的寄存器，明白吗？

45
00:06:52,999 --> 00:07:03,999
然后它访问全局变量也不需要这个[]，直接以全局它的地址，就用这个立即数的符号($)

46
00:07:06,999 --> 00:07:16,999
然后就是这些,总之非常复杂，但是GCC用的就是这一种，没办法，我只好用它

47
00:07:16,999 --> 00:07:26,999
然后就是说就，不是有一种函数嘛，然后这个ret是函数的返回指令，然后这个是赋值指令

48
00:07:26,999 --> 00:07:30,999
所以可以看到这个func() return 42

49
00:07:30,999 --> 00:07:36,685
它被编译成了把42复制给EAX然后返回，

50
00:07:36,709 --> 00:07:45,999
就可以看出我们这个返回值啊是通过EAX传出去的，明白吗？

51
00:07:47,999 --> 00:07:56,999
就是我这里是用这个指令来编译一个cpp文件，变成一个.s文件

52
00:07:56,999 --> 00:08:05,999
然后-s就代表生成的不是.o文件哦，而是而是这个.s的汇编语言文件

53
00:08:05,999 --> 00:08:11,999
然后这个呢,就是可以让生成代码更简洁

54
00:08:11,999 --> 00:08:13,991
然后这个呢，只是嗯，

55
00:08:14,015 --> 00:08:25,999
就是说让它的每一条汇编前面有一个注释，来提示这一条指令代表的是原文件当中的第几行

56
00:08:25,999 --> 00:08:34,334
比如return 42就代表了movl $42 %eax这一行，这就能够便于我们学习

57
00:08:36,292 --> 00:08:44,999
对的，它会自动设置的，不需要你去指定，明白吗？

58
00:08:49,999 --> 00:08:54,814
然后就是这个解释，

59
00:08:54,838 --> 00:09:03,424
然后可以看到我们这里有一个有很多很多参数的那个函数，

60
00:09:03,448 --> 00:09:11,999
然后它有123456个参数，它们是通过寄存器，这些寄存器传入了

61
00:09:12,999 --> 00:09:23,999
然后可以看到它这里先是把所有传入的寄存器给先存到一个堆栈上面

62
00:09:23,999 --> 00:09:30,999
rsp就代表堆栈，而这个-就代表是堆栈上的某一个地址

63
00:09:35,999 --> 00:09:39,999
然后它的返回值不是返回了a吗？

64
00:09:39,999 --> 00:09:43,999
就是说edi它不是存到了a变量吗？

65
00:09:43,999 --> 00:09:55,999
它现在又取出来设为这个返回值，然后调用它的人一看eax就知道它返回了多少，明白吗？

66
00:09:58,584 --> 00:10:05,931
然后就是这个访问地址这个边这个符号就是先弄一个立即数，

67
00:10:05,955 --> 00:10:13,999
就代表它的偏移量，然后是它的寄存器写在()里，是这个意思啊

68
00:10:15,584 --> 00:10:19,999
然后就是刚才不是用这个指令吗？

69
00:10:19,999 --> 00:10:28,999
现在我们可以通过加一个-O3选项，加了这个flag 之后，他就比刚才更优化

70
00:10:28,999 --> 00:10:34,999
就刚才不是还把b,c,d,e,f都传了一遍到栈里吗？

71
00:10:34,999 --> 00:10:41,605
现在直接简单了，直接把a传进去，就给送到eax，

72
00:10:41,629 --> 00:10:47,999
就它只需要一行指令就够了，这就是编译器的自动优化

73
00:10:47,999 --> 00:10:53,999
它发现这几个存到栈，你后来没有用过啊，就是只有这个是用到的

74
00:10:53,999 --> 00:10:57,999
所以它直接把这些指令全部砍掉了

75
00:10:57,999 --> 00:11:03,999
然后它又一想，哎，我这写入了一遍栈，又读了一遍栈，没意思啊

76
00:11:03,999 --> 00:11:10,999
我直接把edi复制给eax不就好了嘛，所以它就优化成了这样

77
00:11:11,417 --> 00:11:19,999
所以开启这个选项之后，它就能够生成更精炼更高效的代码

78
00:11:23,999 --> 00:11:25,999
我在录吗？

79
00:11:25,999 --> 00:11:27,999
应该在录

80
00:11:28,974 --> 00:11:31,082
然后这个就

81
00:11:31,106 --> 00:11:41,974
然后就是除了可以movl 来复制之外，这个汇编语言还支持这个乘法，还有加法之类的指令

82
00:11:41,999 --> 00:11:52,999
比如乘法就是imul后面又多了一个l和movl是一样的，代表它的操作数是32位的

83
00:11:52,999 --> 00:11:56,999
然后看一看这是做了什么事呢？

84
00:11:56,999 --> 00:12:05,178
edi我们知道是代表的a,第一个参数，然后esi就是第二个参数，代表b，

85
00:12:05,202 --> 00:12:08,999
然后这是为什么呢？

86
00:12:08,999 --> 00:12:16,625
看一下这个imull %esi, %eax就代表把eax 乘等于(×=)esi，

87
00:12:16,649 --> 00:12:24,999
也就是eax乘以esi以后，再把结果写回到eax, x86汇编

88
00:12:24,999 --> 00:12:36,751
就是这样，他都是就地乘，没有写入到另一个寄存器的这种，它是一种（没听懂）的

89
00:12:36,751 --> 00:12:53,418
所以就是，这里不是首先是把edi赋值给eax嘛，

90
00:12:53,442 --> 00:13:05,999
所以它就相当于,先就是把eax变成了a，然后再把b乘以到a里面，就变成这个返回值了

91
00:13:07,999 --> 00:13:17,999
然后就是64位的乘法，就是刚才不是说l代表32位嘛，而q就代表64位

92
00:13:18,085 --> 00:13:20,633
所以我们这个long long它是64位的，

93
00:13:20,657 --> 00:13:31,999
然后64位也从e系列寄存器变成r系列寄存器，就更宽了，能存储64位

94
00:13:36,999 --> 00:13:39,540
然后就是整数加，

95
00:13:39,564 --> 00:13:48,999
我们以为它会生成一个addl，也就是add没想到它却变成一个lea指令

96
00:13:48,999 --> 00:13:50,999
lea是什么呢？

97
00:13:50,999 --> 00:13:55,812
可以看到这里是一个地址的那个操作数，

98
00:13:55,836 --> 00:14:04,999
也就是这个地址其实是相当于相当于这个的*(rdi+rsi),就是这样的

99
00:14:04,999 --> 00:14:13,167
lea呢又是加载一个表达式的地址，而不是把这个表达式值给取出来

100
00:14:13,167 --> 00:14:21,538
他取的是这个地址，所以这个就相当于eax等于&*，也就是这两个会抵消，

101
00:14:21,562 --> 00:14:26,999
就相当于eax等于rdi加rsi

102
00:14:27,999 --> 00:14:40,167
所以说这是在妙用这个加载地址指令，把它当做add来操作，它就可以更简练

103
00:14:40,167 --> 00:14:43,999
明白吧？

104
00:14:45,999 --> 00:14:54,999
然后就是leal除了可以直接执行加法，它还可以执行任何一次函数

105
00:14:54,999 --> 00:15:01,999
比如这个表达式，因为它是这里多了一个逗号

106
00:15:01,999 --> 00:15:04,999
8就代表把第二个数乘以了8

107
00:15:05,999 --> 00:15:15,999
因为这种线性变换经常用于地址访问中，所以x86把它做成了这个地址访问的操作符里

108
00:15:15,999 --> 00:15:25,751
然而这个lea呢却能把这个地址不是去读它的值，而是去读它这个地址读出来

109
00:15:25,751 --> 00:15:33,542
所以说这就变成了，我们可以把任何一个一次函数给写在一条指令里

110
00:15:33,999 --> 00:15:41,999
所以说这种一次函数在x86上都是很高效的

111
00:15:43,999 --> 00:15:51,584
然后就是刚才说到这里是，为什么要线性变换做成指令呢？

112
00:15:51,584 --> 00:15:57,298
就是为了针对这种情况，比如func(int*a, int* b)然后a是一个指针，

113
00:15:57,322 --> 00:16:07,538
然后我要返回a[b]这时候你会想a这个是怎么知道a[b]的地址，然后读它呢，

114
00:16:07,562 --> 00:16:14,999
你可能会想:哦，那简单,不就是a加b吗？

115
00:16:14,999 --> 00:16:17,367
不行，因为a它是一个int类型的指针，

116
00:16:17,391 --> 00:16:28,459
而如果你直接在汇编里面去a加b的话，它会变成一个char类型的加,

117
00:16:28,459 --> 00:16:35,984
所以说你要char类型的加,加上这个sizeof(int)乘以b,就是像这样，

118
00:16:36,008 --> 00:16:46,999
就是因为int 的大小是4 ，所以这个偏移量也要乘以4才能访问到正确的地址的

119
00:16:46,999 --> 00:16:55,999
所以这里就用了这个x86提供的这个很方便的线性函数来访问

120
00:16:58,292 --> 00:17:01,999
那么这个语句又是啥意思呢？

121
00:17:01,999 --> 00:17:04,167
为什么movslq，

122
00:17:04,191 --> 00:17:13,999
哦，原来就是因为我们刚刚用的int 是32位的，而指针和地址都是64位的

123
00:17:13,999 --> 00:17:25,959
所以说要用这个这个64位的a去加上一个32位的b之前首先要把b转换成64位的

124
00:17:25,959 --> 00:17:34,999
可以看到我们这里是把esi这个32位变成rsi这个64位的了

125
00:17:34,999 --> 00:17:39,626
这样以后才能进行这个线性访问

126
00:17:39,626 --> 00:17:41,958
那么如果要避免呢，

127
00:17:41,982 --> 00:17:48,445
就可以用我们<cstdint>
里提供的std::size_t，

128
00:17:48,469 --> 00:17:56,667
这个size_t它能够保证在64位系统上就是int64

129
00:17:56,667 --> 00:18:02,999
而32位系统上相当于uint32 ，所以就不需要再进行

130
00:18:02,999 --> 00:18:09,125
刚才那个先从32扩展到64 ，它直接就是64位的

131
00:18:09,125 --> 00:18:14,805
所以说它有可能更高效，而且它还有一个好处，

132
00:18:14,829 --> 00:18:26,999
就是比如你这个数组的大小超过INT_MAX，也就是你的数组大到超过2^31次方了

133
00:18:26,999 --> 00:18:32,209
这时候int 就不仅是效率的问题，它是会出错的

134
00:18:32,209 --> 00:18:39,999
所以我们就要用64位的size_t来表示超过了那个大小的索引

135
00:18:40,584 --> 00:18:43,272
明白吧？

136
00:18:43,296 --> 00:18:57,999
所以说建议就是你如果再用于这个下标的话，最好用size_t包括用于循环体的那个int
i=0

137
00:18:57,999 --> 00:19:02,999
i<xxxx，这个也推荐用size_t

138
00:19:03,999 --> 00:19:11,999
然后就是刚才说到的浮点数，什么是浮点数呢？

139
00:19:11,999 --> 00:19:25,458
就比如这种123
，这个是那个这个是整数，然后这个呢就是浮点数，然后浮点数有一个著名的笑话，

140
00:19:25,482 --> 00:19:34,999
就是总之就是0.2加0.1不等于0.3 ，这是为什么呢？

141
00:19:34,999 --> 00:19:37,574
因为浮点数它有精度误差。

142
00:19:37,598 --> 00:19:52,498
不会手写汇编，应该不会吧，不会手写汇编，但是会手写一些编译器指令，比如MM开头的那些东西，行吧？

143
00:19:52,522 --> 00:19:57,999
然后就是说浮点数它不是完美，它是有误差的

144
00:19:57,999 --> 00:20:01,665
就所以说发明了定点数，

145
00:20:01,689 --> 00:20:06,684
就是2000加100 ，然后再除以1000 ，

146
00:20:06,708 --> 00:20:12,375
我们这样就能够保证它没有误差

147
00:20:12,375 --> 00:20:20,999
所以浮点数呢它的好处就是能够表示很大范围内的数，但是它有误差

148
00:20:20,999 --> 00:20:31,999
不过我们高性能编程中经常会用到浮点数，所以说CPU也对他们做了专门的指令

149
00:20:31,999 --> 00:20:42,999
比如add指令，就是刚才不是说addl是代表那个两个32位整数相加嘛

150
00:20:43,999 --> 00:20:49,999
然后这个s呢就代表single ，也就是单精度浮点数

151
00:20:49,999 --> 00:20:52,447
我们的float 就是单精度浮点，

152
00:20:52,471 --> 00:20:57,038
然后addss就代表这两个数相加，

153
00:20:57,062 --> 00:21:00,925
然后他传参数也不是edi,esi了，

154
00:21:00,949 --> 00:21:03,858
他直接用xmm系列，

155
00:21:03,882 --> 00:21:19,811
就是xmm0 就是传a, xmm1就是传b, 然后我们把xmm1加到xmm0
，然后因为正好xmm0是用于返回值的，所以我们这里直接返回了，就可以是a加b了，

156
00:21:19,835 --> 00:21:21,999
明白吗？

157
00:21:26,999 --> 00:21:32,931
参数是0和1 ，返回值是0 ，

158
00:21:32,955 --> 00:21:42,392
然后就是提刚才提到了xmm0这个系列的寄存器，它们都有128位宽的，

159
00:21:42,416 --> 00:21:47,999
它可以容纳四个float 或者两个double

160
00:21:47,999 --> 00:21:59,999
刚才的案例，因为只有一个float 存在一个大128位的计算器，所以只用到了它的最低32位

161
00:21:59,999 --> 00:22:01,999
但是这样有一个问题

162
00:22:01,999 --> 00:22:07,999
因为我们刚才说的是，addss它会只会加最低位

163
00:22:07,999 --> 00:22:12,959
这就要说到这里就是addss什么意思呢？

164
00:22:12,959 --> 00:22:14,999
它要分成三个部分

165
00:22:14,999 --> 00:22:23,375
首先是第一个s它代表的是标量，也就是说只对它最低32位去计算

166
00:22:23,375 --> 00:22:31,999
然后也可以是addps，这时候就会把xmm里所有的四个float 都进行运算

167
00:22:32,999 --> 00:22:40,578
然后就是第二个s它不一样，它代表的是单精度浮点，

168
00:22:40,602 --> 00:22:46,999
也就是float 类型，它也可以是d表示双精度浮点double 类型

169
00:22:47,667 --> 00:22:51,375
然后就所有的排列组合共这四种

170
00:22:53,792 --> 00:22:59,105
第一种是addss是一个float ，addsd一个double，

171
00:22:59,129 --> 00:23:07,999
addps因为xmm有128位可以存四个float，所以他会把四个都进行那个加法

172
00:23:07,999 --> 00:23:14,999
就像这样，就是比如这是xmm0 ，这是xmm1 ，这是xmm0

173
00:23:14,999 --> 00:23:21,999
然后我们把这个加这个存进去，这个加这个，就是同时计算四个的加

174
00:23:21,999 --> 00:23:28,425
但是如果是addss的话，它只会对最低位进行一个加法，

175
00:23:28,449 --> 00:23:35,000
然后其他的位都保留叉xmm0原来的值。明白了吧？

176
00:23:37,999 --> 00:23:40,647
然后这里是省流助手，

177
00:23:40,671 --> 00:23:45,998
就是如果编译器生成了很多大量ss结尾的指令，

178
00:23:46,022 --> 00:23:54,104
那就说明他只是在最低位进行计算，没有进行那个矢量化，

179
00:23:54,128 --> 00:23:56,999
就他可能是比较低效的

180
00:23:56,999 --> 00:24:03,167
但如果大多数都是ps的话，就说明一次能够处理四个float

181
00:24:03,167 --> 00:24:06,999
那这个生成代码就是比较高效的

182
00:24:07,042 --> 00:24:11,417
然后为什么我们需要这些指令呢？

183
00:24:11,417 --> 00:24:16,999
就我直接对单一一个去做加法不就好了吗？

184
00:24:16,999 --> 00:24:19,645
为什么四个打包到一起，因为这样更快呀，

185
00:24:19,669 --> 00:24:23,197
就是把四个打包到一起的话，

186
00:24:23,221 --> 00:24:34,578
它就可以大约就是相当于本来是四个标量的指令，它现在只要一个矢量的指令，

187
00:24:34,602 --> 00:24:37,999
从而它可以快四倍

188
00:24:37,999 --> 00:24:49,542
所以说它在对于那种以计算为主的程序，能够加快它的运行，编译器也会自动去对它进行优化

189
00:24:50,626 --> 00:24:59,500
然后编译器呢，它能够把你对着标量写的代码转换成一个针对矢量的代码

190
00:24:59,500 --> 00:25:10,999
我们待会会给出例子，这种技术称之为单指令多数据，然后英文简写就是SIMD

191
00:25:12,918 --> 00:25:19,498
对呀，没错，两个double 和四个float ，

192
00:25:19,522 --> 00:25:24,958
我们通常用的是四个float这个。

193
00:25:24,982 --> 00:25:31,999
然后就来看一看编译器还有哪些能做的优化

194
00:25:31,999 --> 00:25:37,709
首先一件事是要使它能够执行一些基本代数化

195
00:25:37,709 --> 00:25:50,417
比如看这个例子，这里c是a加b,d是a减b那么它们相加起来是不是b就会被抵消啊，是吧？

196
00:25:50,417 --> 00:25:53,999
然后a加a不是等于2a吗？

197
00:25:53,999 --> 00:25:57,398
那这个括号里就是一个2乘a，

198
00:25:57,422 --> 00:26:00,751
而2乘a除2自然就等于a。

199
00:26:00,775 --> 00:26:07,999
所以编译器很聪明，它直接把a作为返回值，也就是直接给它a了

200
00:26:08,999 --> 00:26:13,947
然后它还有一个点，就是如果我看到a和b都是常量，

201
00:26:13,971 --> 00:26:21,591
然后它们还相加起来，那我不是已经知道这两个常量了，我直接把它拿过来，

202
00:26:21,615 --> 00:26:27,250
然后相加变成42 ，它就直接优化成return 42了

203
00:26:29,974 --> 00:26:34,807
自己去测一下。

204
00:26:34,831 --> 00:26:40,809
然后它更疯狂的是，你甚至可以弄一个for 循环

205
00:26:40,834 --> 00:26:47,334
它看到这个初始值是一个常数，而i每次的值也都是常数

206
00:26:47,334 --> 00:26:54,999
那么它可以把1加到100给优化成直接返回5050 ，没问题的

207
00:26:56,999 --> 00:27:00,291
对呀，编译器其实很厉害啊，

208
00:27:00,315 --> 00:27:08,999
所以你要用好它的话，你甚至不需要影响可读性，你也能够提升性能

209
00:27:08,999 --> 00:27:16,405
然后当然编译器它没那么聪明，就是如果你把代码写的很复杂，

210
00:27:16,429 --> 00:27:20,211
比如用了一些STL容器库，

211
00:27:20,235 --> 00:27:27,425
那它就哎这个arr.push_back()是什么意思啊，它就停止思考了，

212
00:27:27,449 --> 00:27:34,999
它就会放弃优化，干脆就给你去一个个的去调用vector

213
00:27:34,999 --> 00:27:44,999
所以说像vector 这种会在堆上分配内存的容器，编译器通常是不会去进行优化

214
00:27:44,999 --> 00:27:53,999
所以说尽量把你的代码写的简单一点，编译器能够看得懂，它才能帮你优化

215
00:27:53,999 --> 00:27:59,612
如果你用一些很fancy 的，像这种它虽然和原来的结果是一样的，

216
00:27:59,636 --> 00:28:10,591
但你用这么复杂的话，编译器就认为我去优化这段很复杂的那个抽象语法树，它需要花很长时间，

217
00:28:10,615 --> 00:28:14,999
它就觉得不划算，它就放弃优化

218
00:28:14,999 --> 00:28:24,999
就是就是你不要把答案藏的太深，它的那个搜索范围是有限度的，它不会无限制的搜索

219
00:28:24,999 --> 00:28:34,999
所以你要把代码简化，从而它的搜索速度能变短，然后它就能成功的找到正确的优化

220
00:28:35,999 --> 00:28:42,999
看一下这个，这些东西都是存在堆上的

221
00:28:43,999 --> 00:28:48,999
然后这些是存在栈上的，明白吗？

222
00:28:51,999 --> 00:28:53,999
我去喝口水啊

223
00:29:01,125 --> 00:29:09,999
就是比如vector map set 这种，一般来说这些老的容器都是在堆上的

224
00:29:12,999 --> 00:29:15,459
为什么它们要分呢？

225
00:29:15,459 --> 00:29:18,999
就全部存在栈上不好吗？

226
00:29:18,999 --> 00:29:29,417
有区别。就是array， 它是固定大小的，它这是一个缺点，但是它的优点是它可以存在栈上

227
00:29:29,417 --> 00:29:32,999
那为什么vector 不能存在栈上呢？

228
00:29:32,999 --> 00:29:35,251
因为它可以动态的push_back() ，

229
00:29:35,275 --> 00:29:47,999
也就是它的大小是变化的，而栈上呢它只能一次性扩充一定的大小，而不能多次反复的进行扩充

230
00:29:47,999 --> 00:29:55,999
所以这时候就是像map set string 这种可以动态扩展的，它得存储在堆上

231
00:29:55,999 --> 00:30:09,999
也是在堆上，就是你一旦用了一个是，其中一个是存在堆上，那全部都上堆了，知道吧？

232
00:30:12,999 --> 00:30:20,092
就是像unique_ptr 这种，它肯定是去调用了new 和delete 嘛，所以也是在堆上。

233
00:30:20,116 --> 00:30:21,999
像pair呢

234
00:30:21,999 --> 00:30:30,025
就是你要判断最简单的办法就是sizeof(vector<array>)，

235
00:30:30,049 --> 00:30:37,000
你算一下它的大小，它的大小是24 ，这个大小肯定容纳不了多少数据的

236
00:30:37,000 --> 00:30:43,959
所以说它这个存的只是一个指针和vector 的大小数据

237
00:30:43,959 --> 00:30:48,918
而如果你sizeof(array<float, 32>)的话，

238
00:30:48,942 --> 00:30:54,999
你会发现它等于32乘4 ，也就是说它的大小是很大的

239
00:30:54,999 --> 00:31:06,042
你只要算这个sizeof ，你就知道它存的是一个指针还是实际的数据。没法用

240
00:31:06,042 --> 00:31:08,257
左值？

241
00:31:08,281 --> 00:31:12,438
array怎么没法用左值啊？

242
00:31:12,462 --> 00:31:19,358
我记得这种也可以的吧，这种也可以的吧，

243
00:31:19,382 --> 00:31:22,375
tuple也可以用左值的呀

244
00:31:24,083 --> 00:31:30,999
没理解你的意思，像这种是不行的，但tuple 肯定是可以用左值的

245
00:31:33,876 --> 00:31:42,999
总之就是刚才那个如果你改成array是不是能优化成功呢？

246
00:31:42,999 --> 00:31:49,971
试试看，就是我现在改了，哎，还是优化失败，那我再改一下，

247
00:31:49,995 --> 00:31:54,872
改用手写的reduce，它还是优化失败。

248
00:31:54,896 --> 00:32:00,798
我再改呢，把这个100改成10呢，它优化成功了，

249
00:32:00,822 --> 00:32:03,974
这是怎么回事呢？

250
00:32:03,999 --> 00:32:15,999
原来就是代码如果很复杂的话，编译器就放弃优化，因为这样会让它的编译时间变长

251
00:32:15,999 --> 00:32:21,999
所以如果你的代码很简单，那你其实不需要什么优化手段

252
00:32:21,999 --> 00:32:26,999
他能够理解你在干什么，那他就能优化，知道吧？

253
00:32:27,999 --> 00:32:34,698
当然如果你这个的确是想要100这么大，让它自动在编译器求值，

254
00:32:34,722 --> 00:32:37,999
也可以用constexpr语法

255
00:32:37,999 --> 00:32:46,999
这个时候这个函数就强制编译器在运行时求值，从而就可以让它花费很长的时间

256
00:32:46,999 --> 00:32:50,999
但只要会让编译变慢，这是一个缺点

257
00:32:55,999 --> 00:33:01,999
所以说如果你觉得编译器想要迫使它优化，就用constexpr 函数

258
00:33:01,999 --> 00:33:06,999
这样不管你这个花多少时间，它都会去那个

259
00:33:06,999 --> 00:33:10,318
但是constexpr有个问题，因为它

260
00:33:10,342 --> 00:33:19,999
必须让编译器理解全部，所以它必须全部都是分配在栈上的，而不能分配在堆上

261
00:33:19,999 --> 00:33:29,912
就是据说 C++20开始vector
就可以分配在编译期分配了，然后new 和delete 也可以constexpr了 ，

262
00:33:29,936 --> 00:33:39,999
但是 C++17还不行，
C++17的constexpr还是只能用std::array这些在栈上的容器

263
00:33:42,959 --> 00:33:49,999
然后你甚至可以就是把它作为一个宏，那个这叫什么来着？

264
00:33:49,999 --> 00:33:57,999
总之就是它即使这个数在再大，它也会去算，但是会非常非常非常的慢

265
00:33:57,999 --> 00:34:02,999
因为这5000次，50000次迭代是在编译器进行的

266
00:34:02,999 --> 00:34:11,876
然后是我们第二章。很多同学感兴趣，他就是说那个内联函数要怎么用啊

267
00:34:11,901 --> 00:34:14,999
你今天来解释一下

268
00:34:14,999 --> 00:34:21,375
首先函数分为两种，一种是外部的函数，一种是内部的函数

269
00:34:21,375 --> 00:34:23,999
什么是外部函数呢？

270
00:34:23,999 --> 00:34:32,999
就是像这种只要一个声明，然后实际的实现在另一个文件的这种就叫外部函数

271
00:34:33,792 --> 00:34:40,083
这种呢编译器没办法优化，它只能生成一个call指令来调用这个函数

272
00:34:40,999 --> 00:34:48,584
然后PLT，如果你感兴趣的话，可以看一下这里

273
00:34:48,974 --> 00:34:54,331
然后这个PLT出现就代表这个函数是外面的函数，

274
00:34:54,355 --> 00:35:00,385
它会在链接的时候，如果另一个文件定义了_Z5otheri的这个符号，

275
00:35:00,409 --> 00:35:04,974
它就会把那个符号的地址给填充到这里

276
00:35:04,999 --> 00:35:09,304
所以说如果你别的函数里没有定义_Z5otheri,

277
00:35:09,328 --> 00:35:14,999
它这里就没办法填充，从而链接器就会报错

278
00:35:16,999 --> 00:35:22,718
然后还有一个就是这是没开优化，开优化以后就没有call指令了，

279
00:35:22,742 --> 00:35:28,542
他直接跳转到这个jmp的other这个地址

280
00:35:28,542 --> 00:35:35,999
因为他一样是要返回的嘛，不如让他代为返回，这样也是可以的呀

281
00:35:41,876 --> 00:35:46,999
然后刚才说外部函数会让编译器无法优化

282
00:35:46,999 --> 00:35:51,999
但是如果我们是内部函数呢，什么叫内部函数？

283
00:35:51,999 --> 00:35:56,498
就是声明在声明和定义在同一个文件，

284
00:35:56,522 --> 00:36:00,277
就是它定义在这个func用它的文件，

285
00:36:00,301 --> 00:36:05,999
编译器在编译func的同时，它是看得到other的定义的

286
00:36:06,500 --> 00:36:13,999
就是说它知道那个里面就是什么也没做，直接返回了a,从而它可以优化

287
00:36:13,999 --> 00:36:20,792
也就是说这样的话，它本来是没有开优化，它是会直接去调用的

288
00:36:20,792 --> 00:36:24,292
而开了优化之后，就是这是另一个函数

289
00:36:24,292 --> 00:36:29,999
然后这是调用了它，这个是func 的函数，这个是other 的函数

290
00:36:29,999 --> 00:36:32,847
然后如果开启优化的话呢，

291
00:36:32,871 --> 00:36:41,999
就是它定义在同一个文件里是没有@PLT的,这样链接器也不用去到时候把它替换

292
00:36:41,999 --> 00:36:46,626
然后如果在同一个文件里，而且开启了-O3

293
00:36:46,626 --> 00:36:52,999
这时候我们发现func()根本没有调用other() ，他直接返回了233 ，为啥呢？

294
00:36:52,999 --> 00:36:57,071
因为编辑器看到other就是直接返回a啊，

295
00:36:57,095 --> 00:37:01,999
那我这里是不是可以直接替换成return 233呢？

296
00:37:01,999 --> 00:37:03,999
它只需要这样就够了

297
00:37:04,999 --> 00:37:14,999
这就是内联，它会看到那个函数的实现，从而就直接相当于把这个函数的定义贴到这里

298
00:37:16,250 --> 00:37:18,999
没声明inline也会被内联

299
00:37:18,999 --> 00:37:21,999
你看这个案例，我用inline了吗？

300
00:37:21,999 --> 00:37:23,999
你看我用inline了吗？

301
00:37:23,999 --> 00:37:31,999
它自动帮你inline了，所以inline这个关键字它不是说一定要加好吗？

302
00:37:31,999 --> 00:37:41,999
这个关键字是没用的，它不是用来做这个的，它有别的用，但它不是用来内联的，知道吗？

303
00:37:41,999 --> 00:37:44,014
你看我这没用inline，

304
00:37:44,038 --> 00:37:51,751
编译器只要看得到这个函数体就行了，它自动帮你inline，不需要你去指定

305
00:37:51,999 --> 00:38:02,999
可以看到这里是直接优化了，就是说只要在同一个文件就行了，不要什么inline关键字啊

306
00:38:03,042 --> 00:38:12,999
然后就是局部可见函数，就是...哎呀,这里截图错了，这里应该有个static

307
00:38:12,999 --> 00:38:14,725
也就是说

308
00:38:14,749 --> 00:38:20,338
如果我other声明为static，就代表只有这文件可见，

309
00:38:20,362 --> 00:38:23,999
然后它就干脆不生成other函数了

310
00:38:23,999 --> 00:38:26,999
这样的话它还是可以内联

311
00:38:26,999 --> 00:38:33,999
如果你不是static，它也是可以内联，不过它额外生成other给暴露出来了

312
00:38:35,667 --> 00:38:38,999
然后就是我要diss一下这个关键字

313
00:38:38,999 --> 00:38:41,480
首先在现代编译器中，

314
00:38:41,504 --> 00:38:50,671
它们都足够智能，知道哪些函数要内联，你不需要去提醒它，你看这是提醒前，是这个代码。

315
00:38:50,695 --> 00:38:58,999
提醒后，它还是这个代码，它都帮你内联了，就是说只要它看得见other的函数体

316
00:38:58,999 --> 00:39:04,999
它就能够内联，你加这个关键词根本没用，知道吧？

317
00:39:04,999 --> 00:39:13,999
inline 在 C++ 中有其他功能，但它的功能绝对和内联是没关系的，知道吧？

318
00:39:14,999 --> 00:39:23,145
就是如果你觉得加了inline。哦，我觉得加了inline，编译器可以内联，性能可以提升

319
00:39:23,169 --> 00:39:27,999
你就测测看，你去实测一下时间是不是变快了

320
00:39:28,876 --> 00:39:33,999
你去测一下，你肯定会发现根本没有任何效果

321
00:39:33,999 --> 00:39:43,125
所以说就是我推荐一下你去看这个网站，在这个网站里你能够嗯可以试一下哦

322
00:39:49,417 --> 00:39:53,999
总之这个网站就是相当于一个在线编程网站

323
00:39:55,999 --> 00:40:02,999
你在左边输入那个 C++ 代码，然后右边就能够生成它的汇编代码

324
00:40:02,999 --> 00:40:06,999
然后这个好像还是英特尔支持的

325
00:40:07,042 --> 00:40:10,938
看比如我这里写了一个平方函数，

326
00:40:10,962 --> 00:40:22,164
可以看它这里是自动变成了这些指令，当然你也可以加上这个叫什么优化开关，

327
00:40:22,188 --> 00:40:24,999
可以看到它就优化成这样了

328
00:40:24,999 --> 00:40:32,959
然后你这里也可以选其他产品，其他人家的编译器版本啊什么的都可以

329
00:40:33,999 --> 00:40:36,467
比如我这里换成float ，

330
00:40:36,491 --> 00:40:39,312
然后返回值也换成float ，

331
00:40:39,336 --> 00:40:45,111
可以看到这里就生成了乘法的SIMD指令的标量法。

332
00:40:45,135 --> 00:40:50,631
是不是很方便啊，这个网站。

333
00:40:50,655 --> 00:40:59,724
所以就是现在有些所谓的面试官喜欢考什么register和inline ，我是看不懂的。

334
00:40:59,748 --> 00:41:04,542
这两个东西对优化一点作用都没有

335
00:41:04,542 --> 00:41:07,870
register 在 C++ 中被废除了，

336
00:41:07,894 --> 00:41:16,250
就是说你看编译器都能把一个等差数列优化成直接返回5050了

337
00:41:16,250 --> 00:41:24,999
你觉得你还用提醒他，“啊，这个变量需要用寄存器保存”，你觉得他有那么蠢吗？

338
00:41:24,999 --> 00:41:25,999
没有吧

339
00:41:25,999 --> 00:41:29,527
所以以后就是如果你有什么不懂的，

340
00:41:29,551 --> 00:41:41,709
就比如你觉得这个东西register float
x=num , 然后这样,"哎呀，这样是不是更快呢？"

341
00:41:41,999 --> 00:41:43,999
你看有任何区别吗？

342
00:41:43,999 --> 00:41:46,999
我去掉看看，有任何区别吗？

343
00:41:46,999 --> 00:41:48,999
没有任何区别啊

344
00:41:48,999 --> 00:41:53,999
其实这个关键字就是一个笑话，知道吗？

345
00:41:53,999 --> 00:42:01,999
inline关键字也是个笑话，就是它加不加，编译器都能够自动优化的

346
00:42:01,999 --> 00:42:08,542
但是总有某些叫什么所谓的老师哦，他喜欢教这种

347
00:42:08,542 --> 00:42:16,999
“呦，同学们要擅长写register 和 inline~” ，我怕不都是这个人

348
00:42:16,999 --> 00:42:25,000
这个人导致就是这个人的教材里说，“哎呀，inline 才能内联~”，其实是没有关系的

349
00:42:25,000 --> 00:42:35,999
就是在这个网站多试验一下，然后就能发现这个谭x强的某些东西都是假的，都是假的

350
00:42:37,999 --> 00:42:49,876
总之笑话到此结束，然后就是指针这件事，就是我们知道C语言的历史遗产就是指针

351
00:42:49,876 --> 00:42:55,999
然后我们这里弄一个这个func函数，可以看到它在做什么呢？

352
00:42:55,999 --> 00:43:03,632
它把a指向的值取出来，然后写入到c，然后再把b指向的值写入到c。

353
00:43:03,656 --> 00:43:13,051
那你肯定想：“诶，你看你先复制a到c然后再复制b到c，那第一个语句不是浪费了嘛，

354
00:43:13,075 --> 00:43:19,999
就是我直接把b复制给c不就行了，因为a的值一样被覆盖了嘛”

355
00:43:19,999 --> 00:43:25,999
“为啥编译器明明是开了优化，它还是复制了两遍呢？”

356
00:43:25,999 --> 00:43:27,999
这是为什么呢？

357
00:43:29,751 --> 00:43:30,999
你明白吗？

358
00:43:32,999 --> 00:43:38,758
嗯，就是你可以想一想，如果调用者是这样搞的，

359
00:43:38,782 --> 00:43:44,999
就是他a,b,b他传进去的参数前两个是不一样

360
00:43:44,999 --> 00:43:51,292
但最后一个c和b是同样的地址，那这样优化以后，就是

361
00:43:51,316 --> 00:44:00,999
如果我把这个去掉，那就直接是c=b也就是c是b, 所以就代表b=b,所以b的值没有改变

362
00:44:00,999 --> 00:44:05,627
但是如果不去掉的话，那就是a的值先赋给了b，

363
00:44:05,651 --> 00:44:11,999
然后b的值又赋给了b，这样的最后b里面的值是a里面的值

364
00:44:11,999 --> 00:44:18,999
所以说就是因为这编译器不知道你b和c是不是指向了同一个地址

365
00:44:18,999 --> 00:44:25,999
所以如果它优化掉的话，如果你这两个指向同一个地址，它的结果就不对了

366
00:44:25,999 --> 00:44:36,000
所以编译器它是保守的，它尽可能的就是他宁愿变慢也不要出错，他宁可慢不要错

367
00:44:36,000 --> 00:44:38,571
这是它的哲学。

368
00:44:38,595 --> 00:44:43,171
空是另一回事，空是另一回事了，

369
00:44:43,195 --> 00:44:47,438
空他不考虑，它只管指针别名。

370
00:44:47,462 --> 00:44:54,999
就是比如像这样，就是如果这个c和b相等的话，那你想想看这是什么？

371
00:44:54,999 --> 00:44:57,999
这最后的结果就是b=a呀

372
00:44:57,999 --> 00:45:02,999
而如果你这个优化掉，那这个函数就没有结果了

373
00:45:02,999 --> 00:45:08,999
所以说最后优化之后的结果是不一样的，编译器就不敢优化

374
00:45:08,999 --> 00:45:17,058
如果你想让他放心大胆，告诉它b永远不会等于c的，你可以这样写，

375
00:45:17,082 --> 00:45:20,999
这是gcc特有的__restrict 关键字

376
00:45:20,999 --> 00:45:26,491
它在C语言里是标准，而在 C++ 里却没有标准，

377
00:45:26,515 --> 00:45:33,391
所以需要加上__这两个前缀代表它是当前编译器特定的，

378
00:45:33,415 --> 00:45:40,999
所以__restrict提示以后就是它不会再重复两遍了，它只会重复一遍

379
00:45:40,999 --> 00:45:50,999
也就是说它，你向它保证b和c是不同的值，从而它就可以安全的把这个给优化掉，知道吧？

380
00:45:50,999 --> 00:45:53,732
不是空的问题，不是空。

381
00:45:53,756 --> 00:45:58,584
编译器不考虑空不空的问题，空它自动会出错的

382
00:46:00,417 --> 00:46:02,392
然后呢，restrict，

383
00:46:02,416 --> 00:46:09,999
你可能觉得“哎呀，是不是我程序里每一个出现指针的地方都得加个restrict 呀”

384
00:46:09,999 --> 00:46:14,999
不一定。你只需要非const 的加一个就行了，为什么呢？

385
00:46:14,999 --> 00:46:22,999
因为只有写入会造成这个指针别名的问题，而如果只读的话就没任何问题啊

386
00:46:23,999 --> 00:46:31,999
就是说你在c里面加个restrict，我是说c和任何一个指针都不重复

387
00:46:31,999 --> 00:46:34,999
而b如果再声明一遍，没必要

388
00:46:34,999 --> 00:46:40,352
就是说所以我说,就是所有非const的指针都声明restrict，

389
00:46:40,376 --> 00:46:42,999
const的话就不要声明了啊

390
00:46:44,978 --> 00:46:50,252
可以看到这样它也是优化成功，这其实和Rust有点像，

391
00:46:50,276 --> 00:46:56,978
就是它禁止多个指针指向同一个地址，除非这些指针是const

392
00:46:57,999 --> 00:47:06,999
然后除了restrict是帮助编译器知道，哎呦，这个可以放心优化

393
00:47:06,999 --> 00:47:13,004
还有一个让编译器不要优化的那个修饰符，就是volatile。

394
00:47:13,028 --> 00:47:19,285
可以看到我们这里先是把a赋值为了42
，然后又返回了*a

395
00:47:19,309 --> 00:47:26,792
也就是说，这个时候是先把42写入，然后这里直接被编译器优化成returns 42了

396
00:47:26,792 --> 00:47:36,999
因为它想刚刚我写入的42嘛，但是万一你这个A指针是指向一个多个线程同时在写入的地方

397
00:47:36,999 --> 00:47:45,999
也就是比如我这里赋值了42之后，你这里又有某一个线程插进来，然后把a给修改

398
00:47:45,999 --> 00:47:49,999
这时候这个返回值就可能是不一样的

399
00:47:49,999 --> 00:47:56,250
所以这个时候你可以告诉编译器不要优化这个变量，就是int volatile

400
00:47:56,250 --> 00:48:00,999
这时候它就会硬生生的去写一遍，再读一遍

401
00:48:00,999 --> 00:48:03,999
生怕你这里再插入了什么东西

402
00:48:03,999 --> 00:48:07,999
如果你想优化的话，就不要加volatile了

403
00:48:07,999 --> 00:48:15,805
如果你想要就是有时候是多线程或者是我想要测试这个内存读写有多快，

404
00:48:15,830 --> 00:48:24,051
我就可以用volatile
关键字，然后它就不会优化掉你的读写，从而你可以测试它的性能，

405
00:48:24,075 --> 00:48:27,000
嗯，测试处理器的性能

406
00:48:28,834 --> 00:48:32,626
然后注意一下它们两个区别很大

407
00:48:34,999 --> 00:48:43,999
volatile是在*前面的，而restrict 它毕竟是在*后面，这是语法上区别

408
00:48:43,999 --> 00:48:45,937
功能上，volatile是禁止优化，

409
00:48:45,961 --> 00:48:52,651
而且restrict 是一个帮助优化的形式。volatile是一个 C++ 标准，

410
00:48:52,675 --> 00:48:57,999
而restrict 却不标准，它只是C语言的标准

411
00:48:57,999 --> 00:49:06,999
在 C++ 里不标准，然后__restrict 则是一个GCC编译器特有的那个修饰符

412
00:49:06,999 --> 00:49:13,999
但是碰巧在其他编辑器里，也是前面加两个斜杠子这个修饰符

413
00:49:13,999 --> 00:49:23,999
所以说这又是一个不是标准的标准，但是C艹委员会却没有把它加入，这是为什么呢？

414
00:49:23,999 --> 00:49:26,367
小彭老师也不知道。

415
00:49:26,391 --> 00:49:32,145
对，它们主要就是，volatile 是可以针对不是指针的，

416
00:49:32,169 --> 00:49:35,542
而restrict必定是针对指针

417
00:49:35,999 --> 00:49:38,999
就是比如你可以这样写

418
00:49:44,999 --> 00:49:48,087
就是你这样可以选一个空循环，

419
00:49:48,111 --> 00:49:56,999
编译器一定不会优化掉它，因为int的写入它必须被写入，所以编译器就不会优化掉

420
00:49:56,999 --> 00:50:05,999
比如你这里写一个想要拖时间用的东西就很好用啊，就编译器不会把它优化掉了

421
00:50:05,999 --> 00:50:12,999
这时候就不是指针哦，但通常都是伴随着指针来用的

422
00:50:12,999 --> 00:50:15,174
像这种一般都是，

423
00:50:15,198 --> 00:50:19,812
就是哎呀我跟老板说，哎，你看这个程序性能好差啊，

424
00:50:19,836 --> 00:50:26,999
其实你是在这里偷偷安插一个假的死循环，然后来拖慢他的性能

425
00:50:26,999 --> 00:50:33,999
然后你说：“老板给我打钱！”，然后你就把这一行给删掉，然后它变快

426
00:50:33,999 --> 00:50:38,999
老板说，“哎呀，你真了不起！”，就有这种应用，知道吧？

427
00:50:40,999 --> 00:50:45,905
然后就是说到指针，还有一点，就是

428
00:50:45,929 --> 00:50:52,412
我们这里有两个写入，第一个是针对a[0]
，然后是a[1]，

429
00:50:52,436 --> 00:51:03,709
这两个分别是int，也就是32位的写入。在编译之后出来变成一个q，变成一个64位的写入

430
00:51:03,709 --> 00:51:07,050
因为两个32位它是连续的地址，

431
00:51:07,074 --> 00:51:11,999
所以它能够自动优化成一个64位的写入

432
00:51:13,999 --> 00:51:27,384
对，是没什么关系，但是又是有点关系，就是实际要弄这个多线程一起访问的那个变量的话，会用这个

433
00:51:27,408 --> 00:51:29,167
会用这个std::atomic<int>

434
00:51:30,999 --> 00:51:38,999
而不是用volatile ，总之就是volatile 有时候是有点用的

435
00:51:38,999 --> 00:51:46,792
就比如这个0xb8000，懂的都懂，呃，好像是这个0xb80000，懂的都懂

436
00:51:46,999 --> 00:51:55,999
还有一些就是内存I/O中的东西，这时候写入它是写入到硬件的某一个地址上

437
00:51:56,125 --> 00:52:01,167
就是它有可能随时会改变的意思

438
00:52:03,709 --> 00:52:09,334
然后就是刚才说这种写入能够变成单独一个64位的

439
00:52:09,334 --> 00:52:14,212
但是如果你这中间跳了，比如这是[0][1]可以优化的，

440
00:52:14,236 --> 00:52:17,825
你这变成[0][2]了，中间[1]这个地方空了，

441
00:52:17,849 --> 00:52:26,209
那他没办法优化了呀，他只能变成两个写入32位的，对吧？

442
00:52:27,999 --> 00:52:32,999
你看这是一个四字节，然后这一下子跳到8字节了

443
00:52:32,999 --> 00:52:40,999
它如果再优化成128位的话，这当中有一个a[1]就要被错误的写入了

444
00:52:40,999 --> 00:52:43,999
它不想写错，它只好放弃优化

445
00:52:43,999 --> 00:52:50,718
所以说我们在设计数据结构的时候，尽可能把它设计的紧凑点，

446
00:52:50,742 --> 00:52:57,999
不要把很多无关的变量交错的排列，这样它就很难优化了，知道吧？

447
00:52:57,999 --> 00:53:04,334
然后就是刚才说到是可以把两个int 变成一个int64

448
00:53:04,999 --> 00:53:13,999
那其实还可以把四个int优化成一个__m128 ，也就是xmm寄存器

449
00:53:18,792 --> 00:53:20,720
比如这里有四个int ，

450
00:53:20,744 --> 00:53:31,999
因为四个32位就是128位嘛，所以就可以用我们的xmm来实现一次写入四个int

451
00:53:34,209 --> 00:53:38,999
这是SSE引入的，它是128位的哦

452
00:53:38,999 --> 00:53:45,999
它本来是存储四个float 的，但它其实也可以存四个int没问题

453
00:53:46,999 --> 00:53:50,999
然后为什么叫movups呢？

454
00:53:50,999 --> 00:54:00,999
之前都是没有这个u的，这个u就是mov特有的，它代表这个地址不一定会对齐到16字节

455
00:54:01,999 --> 00:54:04,250
也可以是movaps

456
00:54:04,250 --> 00:54:13,667
这时候它就是你向它保证rdi一定是对齐到16字节的，这样可能有微乎其微的提升

457
00:54:13,999 --> 00:54:24,999
然后就是刚才说的四个可以变成128 ，然后八个就可以变成256 ，这个是ymn寄存器

458
00:54:24,999 --> 00:54:33,999
但为什么我明明这样写，它却用了两个xmm的寄存器，而没有优化成一个ymm呢？

459
00:54:33,999 --> 00:54:35,125
这是为什么？

460
00:54:35,125 --> 00:54:40,785
这是因为它不敢保证你的电脑支持AVX，

461
00:54:40,809 --> 00:54:51,311
就是说编译器它只能生成，它只能保证因为所有的64位电脑都支持xmm，所以说它

462
00:54:51,335 --> 00:54:53,999
只能保证xmm是可以用的

463
00:54:53,999 --> 00:55:01,999
而256位的YMM只有一些比较新的电脑上才有，它就不敢用了

464
00:55:03,167 --> 00:55:13,999
所以说你要让他敢用，可以加这个flag ，跟它说，你来检测一下我的电脑是否支持AVX

465
00:55:13,999 --> 00:55:19,999
如果我的电脑支持，那你就可以用ymm优化了

466
00:55:19,999 --> 00:55:29,042
比如这里我写了八个，它也的确用了ymm读取一次，然后写入,嗯,就更高效了

467
00:55:33,999 --> 00:55:40,225
然后就是说但是这个有一个问题，就是如果你这个编出来的程序，

468
00:55:40,249 --> 00:55:45,999
你要送给一个没有AVX的电脑上去运行就不行

469
00:55:45,999 --> 00:55:53,999
所以如果你用于发布的话，最好还是不要用这个flag哦，然后就是数组的清零

470
00:55:53,999 --> 00:56:02,999
就是我们可以看到这里什么事也没做，他只是清零，没有调任何标准库函数哦

471
00:56:02,999 --> 00:56:08,999
而看到这里，它却变成了一个对memset 的调用，为什么呢？

472
00:56:08,999 --> 00:56:14,626
因为编译器那个是和那个标准库绑定的

473
00:56:14,626 --> 00:56:23,999
所以说如果你在这里生成一个像是把整个数组清零操作，它会识别到，然后就能够变成

474
00:56:23,999 --> 00:56:33,445
哦你记得 C++ 是吧，那标准库肯定是可以用的，它直接变成了一个对标准库的调用了

475
00:56:33,469 --> 00:56:40,999
就不需要你自己手动写memset(a, 0, n*sizeof(int))

476
00:56:40,999 --> 00:56:49,999
你只要这样写，它能够自动优化成对标准库的调用，而标准库里面的实现通常是更高效的

477
00:56:53,999 --> 00:56:56,999
然后就是memcpy也是同理

478
00:56:56,999 --> 00:57:02,152
比如这有个b,然后a[i]=b[i]它也能够自动变成这个

479
00:57:02,176 --> 00:57:06,999
对memcpy 的调用，就你不需要自己去写

480
00:57:06,999 --> 00:57:11,999
然后就是SIMD加速的问题

481
00:57:11,999 --> 00:57:21,751
就是刚才不是说这里有一个从0到1024 ，然后填入到这个a[]数组，对吧？

482
00:57:23,999 --> 00:57:29,209
就是说首先它这是在干什么呢？

483
00:57:29,209 --> 00:57:39,999
是不是挺难看懂的，我来分析一下它在做什么，它就是把左边这个优化成右边这样，看懂了吗？

484
00:57:39,999 --> 00:57:48,542
就是int i=0 ，i<1024 ，i+这里变成加等于四了，就是一次可以写入四个

485
00:57:48,542 --> 00:57:53,490
然后我们这里在a[i]写入这0,1,2,3,四个数，

486
00:57:53,514 --> 00:58:01,918
然后在下一步的时候把curr给全部加上4 ，然后这里就变成了4,5,6,7了，

487
00:58:01,942 --> 00:58:07,725
这时候再写入就是4567 ，然后再加一下，就是8,9,10,11，

488
00:58:07,749 --> 00:58:16,125
这样和原来的那个运行结果完全一致，但却能够就是更加高效

489
00:58:16,125 --> 00:58:27,999
因为它是用SIMD指令并行的去加入，明白了吧？

490
00:58:27,999 --> 00:58:37,626
但是这样有一个缺点，就是因为我这是i+=4

491
00:58:37,626 --> 00:58:41,584
如果这里不是1024 ，而是1023的话，

492
00:58:41,608 --> 00:58:52,292
那它这里就会多写入一个int ,查这个地址可能是别人的数据就把它覆盖掉，怎么办呢？

493
00:58:52,999 --> 00:58:55,674
可以用边界特判法，

494
00:58:55,698 --> 00:59:02,225
我们用这个主要是我们刚才是一个固定的1024,编译器看得到，

495
00:59:02,249 --> 00:59:06,876
这是一个四的倍数，可以直接这样写

496
00:59:06,876 --> 00:59:11,375
但是如果n是不确定的，可能不是四的倍数呀

497
00:59:11,375 --> 00:59:16,999
所以这时候它就生成了这个超复杂的代码，这是啥意思呢？

498
00:59:16,999 --> 00:59:26,999
它做的事就假如n是1023的话，他会先把它变成一个刚才优化过的1020个元素的填入

499
00:59:26,999 --> 00:59:36,999
然后每次可以除以四个，然后还剩下三个是没办法直接一次写入了，它就变成了传统的标量模式

500
00:59:36,999 --> 00:59:38,999
然后每一个处理一个

501
00:59:38,999 --> 00:59:48,152
所以这种思想呢就是如果我的n不是4的倍数，那我先取出其中和4整除的部分，

502
00:59:48,176 --> 00:59:52,999
然后剩下不整除的部分，再用低效的标量代码去做处理

503
00:59:52,999 --> 01:00:01,999
这样大部分1020个数据都是矢量化的加，而剩下的三个数据才是标量加

504
01:00:01,999 --> 01:00:11,999
所以说它既高效又不会犯错，这就是边界特判，就是编译器做优化的时候，它能够自动去判断

505
01:00:11,999 --> 01:00:19,751
可以看到这里做了什么，做了一个cmpl，然后它就会比较n是不是4的倍数啊

506
01:00:19,751 --> 01:00:22,999
如果是的话，我就直接全部填入

507
01:00:22,999 --> 01:00:31,999
如果不是的话，我先取出它剩余的那三个元素，然后先把全部填入之后，我再进行一个收尾工作

508
01:00:31,999 --> 01:00:34,500
编译器能自动处理

509
01:00:34,500 --> 01:00:43,999
但如果你要自己手动去写MM什么什么的SIMD指令的话，你就要手自己去判断这个边界

510
01:00:43,999 --> 01:00:45,999
哦，明白了吧？

511
01:00:51,999 --> 01:00:59,585
然后如果你能够保证n总归是4的倍数，不想让它这么复杂生成两个版本，

512
01:00:59,609 --> 01:01:02,999
你可以用这个n先除以4

513
01:01:02,999 --> 01:01:07,999
因为除是整除就让n会落入4的倍数当中

514
01:01:07,999 --> 01:01:17,999
这样的话编译器能够发现n始终是4的倍数，从而它就不会生成边界特判的分支了

515
01:01:18,334 --> 01:01:27,105
是不是很智能？编译器甚至能够理解这个术语函数的用途诶。

516
01:01:27,129 --> 01:01:34,834
是啊是啊，所以我推荐所有的数组都是4的整数倍

517
01:01:34,834 --> 01:01:42,999
如果可以的话，最好再弄成16的整数倍，这样能够避免边界特判的发生

518
01:01:42,999 --> 01:01:48,999
然后再写一下这个告诉编译器，我肯定是四的倍数

519
01:01:49,417 --> 01:01:56,318
然后就是

520
01:01:56,342 --> 01:02:03,852
这个GCC内置的那个函数，它都是以两个下划线，然后builtin 开头的，

521
01:02:03,876 --> 01:02:10,459
就是这个就告诉编译器，我保证a是16字节对齐的

522
01:02:10,999 --> 01:02:13,165
然后看看和刚才有啥区别，

523
01:02:13,189 --> 01:02:19,031
刚才是movups，这里面成了movaps，

524
01:02:19,055 --> 01:02:30,999
这个就让CPU知道，这个保证是16字节对齐的，传CPU可能就更快一点，也可能不快

525
01:02:33,999 --> 01:02:37,999
是这样的话就是调用GCC才用的函数

526
01:02:37,999 --> 01:02:41,218
如果在微软编译器上，就不能通过。

527
01:02:41,242 --> 01:02:47,865
所以说为了通用， C++20在<memory>头里引入这个模板函数，

528
01:02:47,889 --> 01:02:52,542
然后通过模板参数来指定对齐到16字节

529
01:02:52,542 --> 01:02:56,834
但是它是20的事了，我们目前还用不上

530
01:03:03,709 --> 01:03:10,999
然后是小彭老师也没看懂，就是我是在对a的所有值进行一个加

531
01:03:10,999 --> 01:03:18,999
,就是把数组里所有的元素加起来，结果它生成了这么复杂的一串代码

532
01:03:20,999 --> 01:03:34,999
总之它就是高效。小彭老师也不知道为什么-_-|||。嗯，然后就是讲循环了

533
01:03:34,999 --> 01:03:45,417
因为在那个我们的程序中就是有热和冷这两个术语，它说的是热，就是经常被访问的代码

534
01:03:45,417 --> 01:03:52,978
就比如刚才这一段float ret=0 ，它只会调用一次，

535
01:03:53,002 --> 01:03:58,999
而这个for 循环里面的这个东西被调用了1024次

536
01:03:59,999 --> 01:04:07,999
所以说这个调用次数多的地方称之为热，然后调用数少的地方称之为冷

537
01:04:07,999 --> 01:04:11,999
一般我们优化都是在热的地方优化

538
01:04:11,999 --> 01:04:15,658
因为热的地方通常它执行过很多遍，

539
01:04:15,682 --> 01:04:24,999
也就是说更容易成为瓶颈，而往往循环中的那个地方都能执行很多遍

540
01:04:24,999 --> 01:04:32,000
所以说优化通常都是针对循环的优化，而循环也往往是优化的重点

541
01:04:32,999 --> 01:04:45,098
所以说这里出现了一个用循环的那个func函数，它的工作就是把b[]里面的数加1
，然后复制到a[]。

542
01:04:45,122 --> 01:04:54,999
可以看到这发生了什么，就是按我们的理解，这个应该是可以矢量化的吧

543
01:04:55,999 --> 01:05:00,999
但是编译器却生成两个版本，为什么呢？

544
01:05:00,999 --> 01:05:10,792
因为它生怕就比如b等于a+1的话，这样写入a之后，b的值就会被改变

545
01:05:10,792 --> 01:05:19,999
然后这时候它就有可能他就优化之后这个运行的结果就会不一样

546
01:05:19,999 --> 01:05:26,999
所以说编译器就不敢优化，但是它又想要追求性能怎么办呢？

547
01:05:26,999 --> 01:05:28,307
它离天下之大谱，

548
01:05:28,331 --> 01:05:31,506
它竟然对指针进行了一个判断，

549
01:05:31,530 --> 01:05:47,999
就是判断a+1024是否小于b或者b+1024小于a,
如果这两个小于了，也就是不重合，它才会去调用SIMD这个高效的版本

550
01:05:47,999 --> 01:05:54,999
如果如果我们这个出现了重合，它就会跳转到这个低效的版本

551
01:05:54,999 --> 01:06:03,999
但是它能够保证不出错，嗯，是不是很离谱，就是因为他怕这两个指针是有重合的

552
01:06:03,999 --> 01:06:12,999
虽然我们知道它没有重合是不是，这合理吗？

553
01:06:12,999 --> 01:06:15,999
然后就有这个表情包

554
01:06:15,999 --> 01:06:19,391
所以说我们为了让编译器放心，

555
01:06:19,415 --> 01:06:27,999
可以加上这个float *__restrict ，就告诉编译器这两个数组保证不会重合

556
01:06:27,999 --> 01:06:37,292
这样的话它就只生成了一个SIMD版，而不需要在运行时判断是不是有重合了

557
01:06:37,292 --> 01:06:48,999
这样的话它效率可能就能够提升，因为不需要分支嘛，这才叫“很合理”的解决方案

558
01:06:49,999 --> 01:06:54,999
多一个判断，但是生成的代码不是变多了吗？

559
01:06:54,999 --> 01:07:05,999
就如果你这不是1024 ，而是比如64的话，那这个多一个分支就有可能就能够成为瓶颈了

560
01:07:05,999 --> 01:07:14,999
总之就是还有一种情况，就是如果我这里不止a和b,而是abcdefg有很多个

561
01:07:14,999 --> 01:07:18,999
那这从编译器就是每个都判断一遍

562
01:07:18,999 --> 01:07:25,491
而由于刚刚说的编译器不会优化过于复杂的代码，

563
01:07:25,515 --> 01:07:31,999
它会认为把ABCDEFG每一个去比一遍，是一个非常复杂的操作

564
01:07:31,999 --> 01:07:41,999
所以它甚至有可能放弃这个去进行判断，然后直接生成一个标量版给你，知道吧？

565
01:07:42,999 --> 01:07:49,218
所以说加上一个restrict 就告诉他，哎呀，我保证它们不会重复，

566
01:07:49,242 --> 01:07:53,334
然后它就能生成矢量的代码了

567
01:07:55,999 --> 01:08:04,999
然后除了可以用这个GCC特有的restrict ，也可以使用比较跨平台的openMP

568
01:08:05,667 --> 01:08:07,999
openMP是什么呢？

569
01:08:07,999 --> 01:08:15,305
它是高性能计算的一个框架，它可以通过-f openMP来打开，

570
01:08:15,329 --> 01:08:22,999
然后使用起来只需要用#pragma omp simd语句，就行了

571
01:08:22,999 --> 01:08:29,898
它就告诉你，哎呀，下面这个有可能会出现那个数据依赖，但是不要担心，

572
01:08:29,922 --> 01:08:34,131
我放心你，你一定能把它深入的优化的。

573
01:08:34,155 --> 01:08:42,652
这样编译器就知道你都显式说的simd啊，那我应该能够默认你这两个指针不会打架了，

574
01:08:42,676 --> 01:08:46,999
从而它也是只会生成一份代码

575
01:08:46,999 --> 01:09:00,999
然后除了可以这两种之外，如果你只用GCC的话，还可以用这个ivdep 这个pragma

576
01:09:00,999 --> 01:09:03,999
然后它是什么的简称呢？

577
01:09:03,999 --> 01:09:08,999
ignore vector dependency 就是忽略矢量依赖关系

578
01:09:09,999 --> 01:09:19,999
就是说它可以就是忽略这个b可能会依赖于a的情况，然后这个是GCC特有的

579
01:09:19,999 --> 01:09:25,999
不过其他编译器这个pragma可能就不一样，你可以自己去查

580
01:09:25,999 --> 01:09:35,459
pragma ivdep在MSVC是怎么样的自己去查，但这个就是比较跨平台，比较通用的一个

581
01:09:35,459 --> 01:09:38,999
但是它得开一个选项，明白伐

582
01:09:41,876 --> 01:09:45,999
ivdep 就是忽视vector dependency

583
01:09:46,999 --> 01:09:56,999
然后还有一个循环的优化，就是这种。因为矢量化，它是没办法弄一个if语句的

584
01:09:56,999 --> 01:10:06,999
一旦有if语句矢量化就会很困难，所以说编译器会把这if语句挪到外面，具体是怎样呢？

585
01:10:06,999 --> 01:10:14,785
可以看到这个eax，eax是bool is_mul这个参数的寄存器，

586
01:10:14,809 --> 01:10:22,999
然后它会先判断就是这个是不是为空啊，是不是为真啊

587
01:10:22,999 --> 01:10:25,999
如果为真的话，就跳到L2

588
01:10:26,999 --> 01:10:42,999
可以看到这里面是一个。。。哎呀搞反了，我这里。。。调一下。。。人傻了，应该这样

589
01:10:52,999 --> 01:10:57,999
总之哎呀，哎呀算了，你看得懂就行了

590
01:10:57,999 --> 01:11:03,074
总之呢这上面一个可以看到生成addps的一个循环，

591
01:11:03,098 --> 01:11:06,738
然后下面生成一个mulps，也就是乘法，

592
01:11:06,762 --> 01:11:13,500
它会去提前判断，也就是它相当于进行了这么一个优化

593
01:11:13,500 --> 01:11:18,685
也就是把if提到外面，然后for循环也是分成两份for循环，

594
01:11:18,709 --> 01:11:25,999
这样就可以里面就没有if语句，从而可以矢量化，明白吧？

595
01:11:28,999 --> 01:11:33,727
但是这样我们写起来是更麻烦，所以有时候也可以这样写，

596
01:11:33,751 --> 01:11:42,999
只要编译器知道is_mul 是一个循环之中不会改变的量，它就能够这样优化

597
01:11:42,999 --> 01:11:49,999
就是你们知道有没有同学用taichi啊，就是这个东西有人用吗？

598
01:11:49,999 --> 01:11:52,494
如果你用这个东西的话，

599
01:11:52,518 --> 01:12:00,705
你也可以把if提到外面， 然后外面这里弄一个if ti.static，这样也能够变快，

600
01:12:00,729 --> 01:12:01,999
知道吧？

601
01:12:04,125 --> 01:12:09,999
这样就可以用SIMD优化了，因为没有if指令

602
01:12:09,999 --> 01:12:17,667
然后除了这种可以挪到外面来的if,还有可以挪到外面来的表达式

603
01:12:17,999 --> 01:12:21,047
比如这里优化之前是长这样的，

604
01:12:21,071 --> 01:12:29,999
优化之后它发现,哎这个dt*dt这dt不是随着循环不会改变的吗？

605
01:12:30,999 --> 01:12:33,714
那如果我这样，就是

606
01:12:33,738 --> 01:12:41,999
先把dt*dt计算好,之后就直接乘就可以了，就不需要再重新计算1024遍呀

607
01:12:41,999 --> 01:12:47,999
所以我们可以看到这里，它先是进行了一个dt*dt的运算

608
01:12:48,667 --> 01:13:00,918
然后到这里它就直接应用这个这个乘好的%mm0了，就可以节省1024次乘法运算

609
01:13:00,918 --> 01:13:08,999
这种思想就叫什么，会把热的那个代码尽量移到冷的代码里去

610
01:13:08,999 --> 01:13:16,999
也就是说在不是这看起来好像是一个乘从一个地方移到另外一个地方

611
01:13:16,999 --> 01:13:26,999
其实它是把1024次乘移到一个只会乘一次的地方，从而它就能够更快，明白吧？

612
01:13:33,999 --> 01:13:38,999
然后就是你这样其实是有需要加一个括号的

613
01:13:38,999 --> 01:13:41,999
如果你把括号去掉，它会怎么办？

614
01:13:41,999 --> 01:13:51,000
它会因为乘法不是左结合性嘛，所以它会认为是先b[i]乘以dt，然后乘出来结果再去乘dt

615
01:13:51,000 --> 01:14:00,999
从而它发现不了dt*dt是一个不变量，然后它就硬生生乘了两遍，所以编译器是有点蠢的

616
01:14:00,999 --> 01:14:04,999
明明加一个括号是一样的，它发现不了

617
01:14:05,959 --> 01:14:13,999
所以说我们就最好帮编译器像刚才那样打上一个括号，告诉它这里面全是不变量

618
01:14:13,999 --> 01:14:18,999
而这样的话，它因为乘法结合率的原因就不会识别出来

619
01:14:19,999 --> 01:14:25,999
然后还有一个会导致SIMD优化失败的例子，就是调用外部函数

620
01:14:25,999 --> 01:14:30,626
刚刚也说外部函数是优化失败的罪魁祸首

621
01:14:30,626 --> 01:14:36,999
比如这里我弄一个for 循环，本来这只有这个的话是可以优化成功的

622
01:14:36,999 --> 01:14:41,771
而你调用了一个声明在其他文件的函数，

623
01:14:41,795 --> 01:14:49,012
那它没办法矢量化，矢量化它得调用。。。，又不知道这个other是不是会改变a，

624
01:14:49,036 --> 01:14:50,484
它不知道呀，

625
01:14:50,508 --> 01:14:53,598
所以说编译器看不到other里干了啥，

626
01:14:53,622 --> 01:15:01,531
他只好求稳说，哎呀，那我不优化了，我就一个个去调用你吧，

627
01:15:01,555 --> 01:15:02,999
知道吧？

628
01:15:02,999 --> 01:15:07,571
所以说尽可能的把other放在同一个文件里定义，

629
01:15:07,595 --> 01:15:14,545
这样编译器就能够看到，other你啥也没做，我直接把other的调用去掉，

630
01:15:14,569 --> 01:15:20,999
然后这剩下的一个reduction 的代码，它就能够优化了，对吧？

631
01:15:22,999 --> 01:15:24,999
看全部都是ps

632
01:15:24,999 --> 01:15:30,999
我刚刚说过，全是ss说明他优化失败了，都是标量的

633
01:15:30,999 --> 01:15:34,999
如果全是ps的话，就说明优化成功

634
01:15:34,999 --> 01:15:45,999
它用了那个packed ，也就是矢量的代码，对编译器看得到other就可以内联了

635
01:15:45,999 --> 01:15:49,709
不需要声明一个inline哦，不需要

636
01:15:50,999 --> 01:15:56,999
所以说在热的for 循环里，尽量不要调用外部函数

637
01:15:56,999 --> 01:16:05,999
我说热的哦，冷的话没关系，像这种调用1024遍就属于热的哈，热的循环

638
01:16:06,999 --> 01:16:10,999
有问题吗？

639
01:16:16,375 --> 01:16:22,999
然后刚才说到这种调用函数会影响SIMD

640
01:16:22,999 --> 01:16:30,999
然后像这种随机访问也会影响SIMD，就是为什么会失败呢？

641
01:16:30,999 --> 01:16:34,260
因为b[i]每次的值是不确定的，

642
01:16:34,284 --> 01:16:42,999
就是它可能是跳跃的在访问，这时候这个编译器就没有相应的指令能够生成这个

643
01:16:43,999 --> 01:16:50,999
因为它是跳跃的访问，还有一种比较恶劣的情况，就是这种i*2

644
01:16:50,999 --> 01:16:57,538
也就是说这是先访问0 ，再访问2 ，再访问4。。。我们刚刚说的

645
01:16:57,562 --> 01:17:03,518
这种跳跃的访问是不利于SIMD的，但是编译器somehow它智能的很，

646
01:17:03,542 --> 01:17:11,999
它用了一大堆shufps 指令，还是成功的对a进行了那个一定的SIMD优化

647
01:17:11,999 --> 01:17:16,999
所以它这是一个部分成功了，但是比较艰难

648
01:17:16,999 --> 01:17:19,999
所以最好的情况是什么呢？

649
01:17:19,999 --> 01:17:21,458
最好情况就直接a[i]

650
01:17:21,482 --> 01:17:30,999
也就是顺序访问这种情况下，编译器能够只用一个指令就进行一个读写就行了

651
01:17:30,999 --> 01:17:37,667
不需要它再弄那么多，需要shufps指令来那个读取跳跃的数据

652
01:17:37,667 --> 01:17:46,999
所以说对编译器和CPU来说顺序，而且连续的访问才是最理想的，明白吧？

653
01:17:47,999 --> 01:17:49,999
喝口水哦

654
01:17:59,999 --> 01:18:02,274
所以说顺序和连续，

655
01:18:02,298 --> 01:18:11,999
首先顺序就是不能弄一个像一个b下标或者是函数返回值这种这种就影响它的优化

656
01:18:16,999 --> 01:18:21,999
然后还有一个优化方式就是循环展开

657
01:18:21,999 --> 01:18:30,999
像这种我们的循环体非常的简单，就是从i到1024这样出现一个什么问题

658
01:18:30,999 --> 01:18:34,178
你看生成的代码一行是movups，

659
01:18:34,202 --> 01:18:38,698
然后还有一行是addq然后是cmpq

660
01:18:38,722 --> 01:18:43,718
就是说我实际执行计算的指令只有一个，

661
01:18:43,742 --> 01:18:49,999
而进行比较和这个i的加的指令却用了两个，还有一个跳转指令

662
01:18:49,999 --> 01:18:57,978
这样的话就导致一部分的时间，大部分的时间都花在这个跳转和加上了，

663
01:18:58,002 --> 01:19:00,999
而不是用在这个实际的计算上

664
01:19:02,999 --> 01:19:05,999
这时候我们就可以用unroll展开

665
01:19:05,999 --> 01:19:14,025
比如这里就是把四个循环体放在一个循环里，然后这里改成i+=4 ，

666
01:19:14,049 --> 01:19:20,167
这样的话它就有四个mov指令和3个不是mov的指令

667
01:19:20,167 --> 01:19:22,402
这样的话就是4:3，

668
01:19:22,426 --> 01:19:31,999
从而我实际执行计算的时间就更多了，从而就可以避免这个反复比较的这个overhead

669
01:19:37,999 --> 01:19:40,959
对的，数组最好是连续的

670
01:19:45,999 --> 01:19:50,999
所以稀疏矩阵也用数组存就可以吗？

671
01:19:51,999 --> 01:19:57,999
然后我们这里有一个GCC指令可以实现循环展开

672
01:19:57,999 --> 01:20:06,999
当然这个是GCC测定的，而且我目前也没找到什么通用的替代，你得自己去用pragma

673
01:20:06,999 --> 01:20:09,999
GCC unroll 4 后面这个数字可以改

674
01:20:09,999 --> 01:20:13,999
,4 就代表把四个循环体变成了一个

675
01:20:13,999 --> 01:20:17,094
这里看到有四个movups，

676
01:20:17,118 --> 01:20:29,375
你可以根据实际的情况决定要用多少,就是小的循环器，一般都会去unroll
一下，但太大的循环体就不要去unroll

677
01:20:29,375 --> 01:20:39,999
因为它会导致生成代码变大，这样对指令的解码就会造成一定的压力，从而可能可能反而就会变慢

678
01:20:39,999 --> 01:20:52,358
对呀，这个你得自己去测，就是你测，比如你调到4变快，调到8变快了，然后调到16又变慢，

679
01:20:52,382 --> 01:20:56,999
那你就知道8是最好的情况，知道吗？

680
01:20:58,999 --> 01:21:05,999
就是不建议你手动去把它写四遍，建议多用pragma语句去进行

681
01:21:05,999 --> 01:21:11,558
unroll,而且用pragma还有一个好处，就是如果你这是1023的，

682
01:21:11,582 --> 01:21:16,999
它也能够自动它也能够自动生成边界特判的代码

683
01:21:19,999 --> 01:21:28,751
然后就是这章的重点结构体，这是很多同学都会错误的这样去写

684
01:21:28,751 --> 01:21:39,999
就是比如我们这里有一个MyVec ，它里面有x,y2个值，然后我们这里做了什么事呢？

685
01:21:39,999 --> 01:21:41,910
就是a[i].x*=y，

686
01:21:41,934 --> 01:21:50,500
也就是它会使用到x和y这两个成员，然后可以看到生成非常复杂的代码

687
01:21:50,500 --> 01:21:56,999
然后里面有shufps什么的，但它最终还是用到了mulps

688
01:21:56,999 --> 01:22:00,999
也就是说它的确是矢量化成功了

689
01:22:01,999 --> 01:22:07,972
但是如果我们突然就是想把这个改成三维的了，

690
01:22:07,996 --> 01:22:16,209
你就凭空加了一个z.然后我们的func甚至没有任何改变，它这里就全部变成ss

691
01:22:16,209 --> 01:22:20,999
也就是说矢量化失败了，这是啥原因呢？

692
01:22:25,999 --> 01:22:30,265
这是因为我们刚才之所以能够使量化，因为

693
01:22:30,289 --> 01:22:38,999
它把两个MyVec给读出来，然后读到一个SIMD的128位寄存器里了

694
01:22:38,999 --> 01:22:45,512
而如果你这样为三个的话，它如果要读到一个SIMD里，它这里

695
01:22:45,536 --> 01:22:50,999
就是xyzx，然后剩余一个y是没办法读出来的

696
01:22:50,999 --> 01:23:00,542
所以说这时候编译器就尴尬了，它没办法生成一个SIMD的读，所以说要怎么办呢？

697
01:23:00,542 --> 01:23:09,999
就是我们添加一个维度，就是你看这里我根本没用z我只是加了一个z它就一下子变低效

698
01:23:09,999 --> 01:23:16,671
所以如果我们再要让它再变回高效，甚至可以这样直接加一个char
padding[4] ，

699
01:23:16,695 --> 01:23:21,999
这是一个没有任何用处的那个空的变量

700
01:23:21,999 --> 01:23:25,874
然后这时它又能够优化成功了，

701
01:23:25,898 --> 01:23:36,959
就是可以发现，就是如果你的struct 是二的整数幂大小，这时候是有利于SIMD优化的

702
01:23:37,792 --> 01:23:47,083
而如果你像刚才那样是三个一组，这时候它就没有办法对齐，从而就SIMD优化失败

703
01:23:47,999 --> 01:23:55,999
就是说你也知道计算机是一个二进制的东西，它最喜欢的就是二的整数幂

704
01:23:55,999 --> 01:24:04,999
如果你的数组大小都是二的整数幂，结构体大小也是二的整数幂，这时候往往是比较高效

705
01:24:05,999 --> 01:24:12,999
可以看到这里是生成这个ps的代码，从而使运行的矢量化

706
01:24:12,999 --> 01:24:20,999
然后除了刚才这种很困扰的这种直接加一个从来用不到的变量

707
01:24:20,999 --> 01:24:29,745
C++11还新增了，alignas也就是对齐到16字节，

708
01:24:29,769 --> 01:24:38,999
这样MyVec的起始地址，它会对齐到16 ，而且它的大小也会变成16的整数倍

709
01:24:38,999 --> 01:24:47,042
这时候生成的代码其实是一样的，但是又不需要手动加一个char padding

710
01:24:47,042 --> 01:24:50,999
明白了吧？

711
01:24:51,999 --> 01:24:56,167
那是不是说就是哎呀小彭老师我学会了，

712
01:24:56,191 --> 01:25:04,999
我这就回去把我的程序每一个struct都加上alignas ，是不是我程序就能变快呢？

713
01:25:04,999 --> 01:25:08,999
不一定哦，甚至是有可能会变慢

714
01:25:08,999 --> 01:25:18,999
因为的确对齐到16之间也能够帮助SIMD优化，但它只是其中一个点，又不是全部的点

715
01:25:18,999 --> 01:25:21,525
这个结构体变大，还有其他的缺点，

716
01:25:21,549 --> 01:25:31,999
就比如会霸占着你的那个缓存，然后就导致它更容易变成memory
bound ，从而有可能还会变慢

717
01:25:31,999 --> 01:25:39,999
所以说你不能就是把这个当成万能的万金油它不行的，你得考虑实际情况

718
01:25:39,999 --> 01:25:45,999
实际测了以后，如果加了的确变快了，那才去加嘛，对吧？

719
01:25:46,999 --> 01:25:53,258
然后就是其实这个案例最好的办法应该是用这个

720
01:25:53,282 --> 01:26:01,004
刚才说到的这个结构是不是XYZpadding
，

721
01:26:01,028 --> 01:26:02,910
其实就是这样的，

722
01:26:02,934 --> 01:26:09,999
就是先xyz，然后这里空一个padding 然后再xyz再空一个padding

723
01:26:09,999 --> 01:26:13,838
这种结构类型叫Array of Struct ，

724
01:26:13,862 --> 01:26:19,984
它是指的是x,y,z单个对象的属性紧紧凑在一起

725
01:26:20,008 --> 01:26:25,725
什么叫单个对象？ 也就是我一个MyVec的x,y,z是紧凑的，

726
01:26:25,749 --> 01:26:30,398
而与之相对的就是SOA,Struct of Array,

727
01:26:30,422 --> 01:26:33,958
它会把一个对象拆成三个数组，

728
01:26:33,982 --> 01:26:41,999
就是一个对象的x在一个数组里，一个对象的y又在另一个数组里，z又在另一个数组里

729
01:26:41,999 --> 01:26:46,554
这样的好处就是它不需要去考虑padding 了，这是肯定的。

730
01:26:46,578 --> 01:26:47,939
然后它，

731
01:26:47,963 --> 01:26:57,999
而且因为这样，如果你只访问了x那z或者根本没有用到，那这时候就相当于只用到了x,y

732
01:26:57,999 --> 01:27:04,999
而如果你用AOS的话，z和padding 都相当于没有用的那个那个属性

733
01:27:04,999 --> 01:27:13,999
所以如果你刚才只用x和y,那CPU看到你就是在不停的跳着两格读，从而效率是更低的

734
01:27:13,999 --> 01:27:21,545
而如果你用AOS，你只访问x,y没用z那CPU看到你是在访问两个数组啊，

735
01:27:21,569 --> 01:27:25,999
从而它能够用SIMD优化

736
01:27:26,999 --> 01:27:36,999
所以说SOA虽然它好像不符合我们面向对象的思想，但它其实是对CPU更友好的

737
01:27:37,959 --> 01:27:39,999
就来看看怎么做吧

738
01:27:39,999 --> 01:27:43,234
首先是刚才说的比较烂的AOS，

739
01:27:43,258 --> 01:27:50,999
我们用float x,y,z,这样生成的就是一个不能SIMD的代码

740
01:27:50,999 --> 01:27:55,999
然后要怎么变成SOA呢？

741
01:27:56,292 --> 01:28:01,999
就是,你看这种是不是很符合面向对象的想法

742
01:28:01,999 --> 01:28:06,894
就MyVec是一个对象，然后MyVec 包含x,y,z，

743
01:28:06,918 --> 01:28:09,726
我有1024个MyVec

744
01:28:09,750 --> 01:28:14,999
其实这样不太好，就是对性能来说，我们会把它变成这样

745
01:28:14,999 --> 01:28:22,418
就刚才是a[1024]，我现在a[1024]不要了，把它移到MyVec 里，

746
01:28:22,442 --> 01:28:25,709
就是x有1024个,y有1024个

747
01:28:25,709 --> 01:28:30,999
然后访问的时候本来是a[i].x现在变成a.x[i]

748
01:28:30,999 --> 01:28:34,999
就是这个括号换了一下位置

749
01:28:34,999 --> 01:28:40,918
本来是a有1024个，现在每个属性都有1024个

750
01:28:40,918 --> 01:28:47,999
他们分离开来的存储,可以看到这里就用到了ps，从而矢量化是成功的

751
01:28:48,999 --> 01:28:53,064
对的对的，

752
01:28:53,088 --> 01:28:58,765
这样虽然就是说这个不符合面向对象的思想呀，

753
01:28:58,789 --> 01:29:03,891
但是他其实更高效，所以就分到分出两派人，

754
01:29:03,915 --> 01:29:08,030
一种是主张抽象的面向对象编程，

755
01:29:08,054 --> 01:29:13,999
还有一种是面向数据编程，就是data oriented programming

756
01:29:13,999 --> 01:29:17,209
这种在高性能计算中比较常见

757
01:29:17,209 --> 01:29:22,438
而面向对象呢他们的工作就是java 的工作，

758
01:29:22,462 --> 01:29:28,459
就是每天打开一个数据库，然后写入学生信息，然后关闭

759
01:29:28,459 --> 01:29:37,999
而如果我们是DOP的话，就会把一个学生的每一个属性存储到很多个数字里

760
01:29:37,999 --> 01:29:45,045
这样的话如果我只用学生的姓名信息，我只要访问这个姓名数字就可以了，

761
01:29:45,069 --> 01:29:53,999
就不会再去读一遍他的身份证号啊、学号啊什么都读一遍，这样不是浪费了内存嘛，对吧？

762
01:29:54,999 --> 01:29:58,000
是不是这样，其实是对性能更好的呀

763
01:29:59,999 --> 01:30:06,834
然后就是有时候面向对象的人又说，哎呀，你这样太不利于优化了

764
01:30:06,834 --> 01:30:11,999
如果我们想要把MyVec存在一个map 里，那你这样就不行了呀

765
01:30:12,999 --> 01:30:20,205
所以说推出了一种中间解决方案，就四个对象打包乘以SOA，

766
01:30:20,229 --> 01:30:26,834
然后再用n除4的大小的数组打包成一个AOS

767
01:30:26,834 --> 01:30:31,792
这样既有AOS的直观，又有SOA的高效

768
01:30:31,792 --> 01:30:37,999
这里其实就相当于把四个变成一个M128了

769
01:30:37,999 --> 01:30:43,999
但是这种其实也不常用，最常用的还是这个SOA

770
01:30:43,999 --> 01:30:47,999
然后这个东西也能够优化成功

771
01:30:47,999 --> 01:30:51,999
然后他还是我们王鑫磊同学的最爱哦

772
01:30:51,999 --> 01:31:02,999
所以说嗯但是他的缺点就是刚才只需要一个for 循环，都是只需要一个的，这里却需要两个

773
01:31:02,999 --> 01:31:12,999
因为它这里面还有两个下标去访问很麻烦，而且这对随机访问也非常不友好

774
01:31:13,999 --> 01:31:21,999
所以我们测试一下，就是刚才这个就比如这个程序吧，它有x,y,z3个属性

775
01:31:21,999 --> 01:31:25,638
然后我们一个计算的过程是

776
01:31:25,662 --> 01:31:33,832
把它的x,y,z加起来写入到x然后首先第一步优化就是这个

777
01:31:33,856 --> 01:31:39,999
AOS，我们把它优化成SOA，也就是把n移上去

778
01:31:39,999 --> 01:31:45,345
然后这样然后再加上我们每个编译器特有的unroll 语句，

779
01:31:45,369 --> 01:31:50,999
就是GCC是GCC unroll，（没听清）也是这个，然后MSVC也是这个

780
01:31:50,999 --> 01:31:58,745
它就是微软的那个它比较霸气，它直接占据根的那个，它就不需要再GCC了，

781
01:31:58,769 --> 01:32:04,865
所以说我们对每个编译器（），然后把它进行一个unroll ，

782
01:32:04,889 --> 01:32:07,258
然后我们这是测试结果，

783
01:32:07,282 --> 01:32:18,999
首先这是未经优化之前需要811620纳秒 ，

784
01:32:19,999 --> 01:32:22,500
对，mesh 是有这种优化的

785
01:32:22,500 --> 01:32:28,999
我们ZENO里的mesh 也是这样优化，这是原来的那个效率

786
01:32:28,999 --> 01:32:36,452
然后这个是用了16字节对齐以后的效率，它反而变慢了

787
01:32:36,476 --> 01:32:43,711
然后这次如果我把原来的那个代码一点不变，只是加上一个parallel for，

788
01:32:43,735 --> 01:32:49,876
它能够变快到这样，而如果我们用SOA优化的话，能够变成这样

789
01:32:49,876 --> 01:32:57,999
然后SOA再加上这个pragrma omp simd让它忽略那个指针别名能变成这样

790
01:32:57,999 --> 01:33:03,999
然后这是我们用了size_t作为它的下标以后又变快了一点

791
01:33:03,999 --> 01:33:09,778
然后最快的就是我们用的是size_t之后再去unroll ,

792
01:33:09,802 --> 01:33:15,999
可以看到它甚至比我们原来直接加一个parallel还要快

793
01:33:15,999 --> 01:33:17,999
这说明了什么呢？

794
01:33:17,999 --> 01:33:21,959
就是说明parallel for 是给无脑的人用的

795
01:33:21,959 --> 01:33:28,999
它用了以后的确能变快，但是它的加速比永远不会超过CPU的个数

796
01:33:28,999 --> 01:33:39,999
而如果我们认真的去优化一下它的内存布局，从而它可以SIMD优化成功，使它的缓存更加高效

797
01:33:39,999 --> 01:33:43,999
它甚至能够吊打你的并行for。对吧？

798
01:33:43,999 --> 01:33:53,999
然后更好是就是如果我这优化以后再上个并行，这样就比原来还要快，比谁都要快了

799
01:33:53,999 --> 01:34:03,083
然后最傻的是AOSOA它虽然快一点，但它其实还不如SOA呢，对吧？

800
01:34:03,999 --> 01:34:07,999
唉，生存计划是那个游戏吗？

801
01:34:09,999 --> 01:34:12,999
它是 C++ 的游戏吗？

802
01:34:12,999 --> 01:34:20,999
里面这样优化，然后这是我们的那个可以看到这一条绿线是无脑并行

803
01:34:20,999 --> 01:34:24,847
然后这条粉线是我们深度优化，

804
01:34:24,871 --> 01:34:32,999
可以看到深度优化之后，它在低数据量的时候甚至超过了这个无脑并行

805
01:34:32,999 --> 01:34:37,999
因为并行它需要创建很多线程，这也需要时间

806
01:34:37,999 --> 01:34:41,999
所以对于小数据我们甚至超过了它

807
01:34:43,459 --> 01:34:46,999
所以这个按你最高效的是SOA格式

808
01:34:47,999 --> 01:34:53,999
当然不一定所有的案例都可以用SOA就能优化，你得看情况

809
01:34:54,100 --> 01:35:00,971
然后就是就是我们刚才说的都是基于C语言的指针，这个太老了，

810
01:35:00,995 --> 01:35:07,565
我们 C++ 不是喜欢RAII思想吗？ 那就得用STL的vector 容器，

811
01:35:07,589 --> 01:35:09,974
然后出现了什么问题

812
01:35:09,999 --> 01:35:14,827
首先来个经典案例，就是第一章说到指针别名问题，

813
01:35:14,851 --> 01:35:21,999
它不能够保证c和b是不是同一个vector，从而它得生成两遍

814
01:35:21,999 --> 01:35:25,999
然后第一个语句就不能够被优化掉

815
01:35:25,999 --> 01:35:34,999
那么我想,哎那我把这个引用声明struct的行不行？

816
01:35:34,999 --> 01:35:38,954
没有任何效果，你看没有任何效果，

817
01:35:38,978 --> 01:35:44,072
就是你这个vector 里的指针，它是没有上restrict ，

818
01:35:44,096 --> 01:35:47,364
你只是把vector本身做了一个restrict,

819
01:35:47,388 --> 01:35:52,222
编译器是不知道c和a它是不是同一个地址的

820
01:35:52,246 --> 01:35:55,951
所以说结论就是

821
01:35:55,975 --> 01:35:59,957
要么就是用omp simd去

822
01:35:59,981 --> 01:36:08,125
让它忽视那个可能存在的那个指针别名，或者用gcc ivdep也可以

823
01:36:08,125 --> 01:36:13,471
所以 C++ 的缺点就体现在这里，它的自由度太高，

824
01:36:13,495 --> 01:36:19,638
它甚至不能指针a和b里面的data 是不是指向同一个对象，

825
01:36:19,662 --> 01:36:23,042
而Rust 它就能够从语法层面禁止

826
01:36:23,042 --> 01:36:28,999
就如果你同时对一个对象取了可变引用，它就会报错

827
01:36:28,999 --> 01:36:34,999
所以说在Rust 编写这种代码是第一个肯定是会被优化掉的

828
01:36:34,999 --> 01:36:36,999
但 C++ 就不可以

829
01:36:36,999 --> 01:36:41,999
那为什么 C++ 标准会就不禁止一下呢？

830
01:36:41,999 --> 01:36:50,392
因为它一旦禁止就会导致不兼容，而导致不兼容以后就导致他没有所有的历史遗产，

831
01:36:50,416 --> 01:36:52,999
那就和Rust 一样了

832
01:36:52,999 --> 01:36:54,999
那C++就没有任何优势

833
01:36:55,751 --> 01:36:59,999
所以说 C++ 还是得抱着他的遗产

834
01:36:59,999 --> 01:37:06,999
然后我们在（没听清）时候加上一些提示来帮助编译器优化，知道吧？

835
01:37:07,999 --> 01:37:14,999
哦，这个啊，对，这两个结合

836
01:37:17,626 --> 01:37:25,999
总之然后就是刚才不是说SOA比较好嘛，但是如果我用了vector 怎么办呢？

837
01:37:25,999 --> 01:37:29,920
也可以,你可以像这样把vector 移上去，

838
01:37:29,944 --> 01:37:37,124
不过你得保证x,y,z当中一个被push 的时候，三个都被push ，

839
01:37:37,148 --> 01:37:39,417
否则的话这里就会出错

840
01:37:39,417 --> 01:37:45,751
然后这里访问a的大小的时候，也会变成a的x的size

841
01:37:45,999 --> 01:37:57,999
所以说就是这个是要维护三个内存，也是有一点开销的，明白吗？

842
01:37:58,999 --> 01:38:06,626
Unity 啊，那应该是C#啊，怎么会涉及到 C++ 优化

843
01:38:06,999 --> 01:38:10,120
然后就是第八章数学运算，

844
01:38:10,144 --> 01:38:14,758
就是看这个例子他做了什么，

845
01:38:14,782 --> 01:38:19,891
我们这里是接受a参数，然后变成a除2 ，

846
01:38:19,915 --> 01:38:24,999
返回a除2 ，结果它就生成了一个乘，呃，这个是什么呢？

847
01:38:24,999 --> 01:38:33,999
这个其实是浮点数的0.5的意思，也就是说它把一个除法优化成了更快的乘法

848
01:38:33,999 --> 01:38:34,999
为啥？

849
01:38:34,999 --> 01:38:36,999
因为乘法比除法更快呀？

850
01:38:37,999 --> 01:38:45,999
然后还有一个虽然乘法更快，但这里它却没有把除法提取成一个倒数出来

851
01:38:45,999 --> 01:38:48,999
为什么它不能优化呢？

852
01:38:48,999 --> 01:38:57,083
因为它害怕b是0的情况，b是0的话这里得变成INF或者说它会报一个错

853
01:38:57,083 --> 01:39:06,999
这时候编译器就不敢优化，所以我们可以手动进行这个优化，就把1/b先预先计算出来

854
01:39:06,999 --> 01:39:13,058
然后在这里用乘法,就乘以刚才这个倒数和直接除是一样的，

855
01:39:13,082 --> 01:39:22,999
但它能够把嗯能够把1024次除法变成1024次乘法加一次除法

856
01:39:22,999 --> 01:39:27,999
这样其实是更快的，就是你要对这个有概念

857
01:39:28,999 --> 01:39:37,898
1024个乘法，比如乘法所需的时间是1，然后再加一个除法，所需的时间是2

858
01:39:37,922 --> 01:39:40,999
这时候花了1026秒

859
01:39:40,999 --> 01:39:47,999
然后如果我用1024个除法的话，就会花掉2048秒

860
01:39:47,999 --> 01:39:54,999
所以说这个优化虽然总的指令数量增加了，但其实乘法比较快

861
01:39:54,999 --> 01:39:58,999
所以我这个其实是更快的解法，明白吧？

862
01:40:01,375 --> 01:40:04,999
GPU不都是SOA的吗？

863
01:40:06,999 --> 01:40:12,458
我记得GPU它是有一个可以指定的。

864
01:40:12,482 --> 01:40:16,510
戴森球是计算着色器?

865
01:40:16,534 --> 01:40:22,118
不懂不懂，没有玩过这个游戏，

866
01:40:22,142 --> 01:40:26,999
乘法比除法快

867
01:40:26,999 --> 01:40:31,904
然后就是我实在是觉得奇怪，为什么它

868
01:40:31,928 --> 01:40:42,999
要放弃优化，所以说这里就有一个解决方案，就是加gcc -ffast-math 这个选项

869
01:40:42,999 --> 01:40:52,999
加了ffast-math 以后，编译器就能够告诉它啊，对这个数学更加的大胆

870
01:40:52,999 --> 01:40:57,999
也就是说它会把一个除法优化成很多个乘法

871
01:40:57,999 --> 01:41:05,999
但是这样有一个问题，就是如果你的b为零，它就不能保证是不是还正确

872
01:41:05,999 --> 01:41:10,999
所以这就是这个选项不默认开启的原因

873
01:41:10,999 --> 01:41:18,999
因为开启了以后对NAN和无穷大的处理会和IEEE腐朽的标准里不一致

874
01:41:19,999 --> 01:41:24,999
但是它又是一个求稳，然后放弃优化的案例啊

875
01:41:24,999 --> 01:41:32,999
所以说如果你能够保证的话，再加上这个flag 就可以，明白吧？

876
01:41:34,999 --> 01:41:43,999
这个到时候再说，到时候不是有个GPU专题嘛，到时候再讲讲GPU怎么伺候

877
01:41:45,999 --> 01:41:50,107
然后还有一个严重的问题，就是

878
01:41:50,131 --> 01:41:59,999
数学函数，就是你可能就以为sqrt函数就可以了，但是它是接受double 的

879
01:41:59,999 --> 01:42:07,584
就如果你用float 去调用sqrt的话，它也会返回一个double

880
01:42:07,999 --> 01:42:11,999
而且它计算的精度也是基于double 的

881
01:42:11,999 --> 01:42:13,999
从而是比float更慢

882
01:42:14,999 --> 01:42:21,999
而如果你想要调用float 的开根号，其实应该用sqrtf

883
01:42:24,999 --> 01:42:26,999
等一下我卡住了

884
01:42:36,999 --> 01:42:42,832
所以说最好的解决方案应该是 C++ 的这个sqrt函数，

885
01:42:42,856 --> 01:42:51,083
它承载了两个版本，就能够自动根据我拿什么去调用它就自动返回什么类型

886
01:42:51,083 --> 01:42:54,417
所以推荐不要再用C语言的

887
01:42:54,417 --> 01:42:59,999
这个全局的sqrt了，多用用std里的这个吧

888
01:43:00,667 --> 01:43:03,999
当然最坑的一个应该说是abs

889
01:43:03,999 --> 01:43:10,999
如果你用全局命名空间的abs，你会发现这样一个有趣的现象

890
01:43:10,999 --> 01:43:14,999
abs(1.4f)等于1，为什么呢？

891
01:43:14,999 --> 01:43:22,632
因为1.4被隐式的转换成了int 因为ABS它是一个针对int 的函数，

892
01:43:22,656 --> 01:43:26,999
你要用fabs才能调用double 的那个

893
01:43:26,999 --> 01:43:34,999
而如果你想用float 那个得用fabsf...坑人吧，坑人吧

894
01:43:34,999 --> 01:43:38,999
这所以这些函数就是C语言的遗产了

895
01:43:38,999 --> 01:43:43,598
永远不要再用全局变量空间的这几个了，

896
01:43:43,622 --> 01:43:52,518
始终用std前缀，用std::abs,它重载了int，double，float
，都能够支持，

897
01:43:52,542 --> 01:43:57,999
这个就不会出现这种奇怪的那个现象了

898
01:43:57,999 --> 01:44:02,900
当然pow 和sin都是，pow 有一点区别，

899
01:44:02,924 --> 01:44:11,298
然后就是还有一个ffast-math 的一个优点，就是

900
01:44:11,322 --> 01:44:18,999
比如我这里是对a的每一个数求根号，为啥它没有矢量化呢？

901
01:44:18,999 --> 01:44:22,999
因为它生怕a某一个数是负数

902
01:44:22,999 --> 01:44:30,999
那么这个时候就比如a[1]是负数，那么计算到a[1]就会出错，然后停止

903
01:44:30,999 --> 01:44:38,964
但是如果你矢量化的话，那就变成a出错了以后，但是a[0]已经写入了，

904
01:44:38,988 --> 01:44:42,999
从而它就不能保证这个写入的顺序

905
01:44:42,999 --> 01:44:46,999
所以它就不敢那个优化，知道吧？

906
01:44:47,876 --> 01:44:55,858
所以说我们开启ffast-math以后，你就告诉它不要怕，我能够保证a绝对不会出错，

907
01:44:55,882 --> 01:44:59,170
它就能够优化成通过这个，

908
01:44:59,194 --> 01:45:03,498
然后还有这些我也不知道是什么的东西，

909
01:45:03,522 --> 01:45:10,999
总之它就是可能是用了一个额外的牛顿迭代，让它进入更高

910
01:45:11,999 --> 01:45:19,999
我看不懂，但大受震撼，小彭老师也看不懂，大家也不需要去看懂

911
01:45:19,999 --> 01:45:24,209
总之它这个fast之后时候应该是会更快的

912
01:45:25,999 --> 01:45:35,167
然后还有一个问题，就是今天我们的作业，就是关于这个，有一个嵌套循环，这个很常见吧

913
01:45:35,167 --> 01:45:40,999
在计算卷积或者是那个矩阵乘法都会用到这个吧

914
01:45:40,999 --> 01:45:51,999
但如果你直接这样显示有问题的，可以看到这里有可能a和c是重合的，甚至b和c是重合的

915
01:45:51,999 --> 01:45:55,999
所以编译器，生怕指针出现别名所以不敢优化

916
01:45:55,999 --> 01:46:04,999
所以刚才不是还有人说，哎呀，嗯这个指针别名不用怕，它不是会生成两个版本吗？

917
01:46:04,999 --> 01:46:11,667
结果它这你看只生成了一个版本，没有生成SIMD版本，为啥？

918
01:46:11,667 --> 01:46:20,999
因为我说的就是编译器当碰到问题复杂化的时候，它直接睡大觉，它放弃优化了

919
01:46:20,999 --> 01:46:26,058
就是它担心c和a会重合，又担心b和a会重合，

920
01:46:26,082 --> 01:46:35,083
它要连续判断三个之间的排列组合是不是重合，它觉得太复杂，它索性放弃了矢量化

921
01:46:35,083 --> 01:46:40,125
所以说这时候要么我们就给a,b,c都加上restrict，

922
01:46:40,149 --> 01:46:46,258
要么就可以用这种方式:先把c读出来，读到tmp ，

923
01:46:46,282 --> 01:46:50,999
然后对tmp 进行追加，然后读完之后再写回到c

924
01:46:50,999 --> 01:46:55,999
这样的话呢，也是对那个寄存器更加友好

925
01:46:55,999 --> 01:47:04,667
因为这时候tmp 相当于在寄存器里就不会重复写入这个全局的那个那个地址吧

926
01:47:04,667 --> 01:47:11,091
这样的话编译器就认为不管有没有指针别名，我都是提前读取了c，

927
01:47:11,115 --> 01:47:14,999
就不管c怎么写入，a和b都不会变

928
01:47:14,999 --> 01:47:17,999
所以它从而能够优化成功

929
01:47:21,959 --> 01:47:26,999
当然一种更好的解决方法就是把tmp 初始化为零

930
01:47:26,999 --> 01:47:29,465
看啊这里是先读出了c[i]，

931
01:47:29,489 --> 01:47:31,778
我这里直接初始化为零，

932
01:47:31,802 --> 01:47:35,278
然后再把这个tmp +=到C[i]，

933
01:47:35,302 --> 01:47:38,905
这样不是没区别吗？ 有区别

934
01:47:38,929 --> 01:47:45,718
因为刚开始这种加法是在c[i]已经有值的情况下去加，

935
01:47:45,742 --> 01:47:53,999
这样如果c[i]是一个，比如1000，而a是个0.01的值，这是它们两个的那个指数

936
01:47:53,999 --> 01:48:01,025
就是你知道浮点数的构造，它有一个指数，有一个底数，而指数相差太大的话，

937
01:48:01,049 --> 01:48:04,999
它们两个之间相加的精度就会受损

938
01:48:04,999 --> 01:48:13,709
就比如1000加0.000001 ，可能还是一千，就导致加出来的结果可能会不对

939
01:48:13,709 --> 01:48:22,999
所以我们最好是把tmp初始化为零，然后这样再去加这手加出来的话就会更准确

940
01:48:23,999 --> 01:48:27,867
然后再加完之后再一次性加到c,

941
01:48:27,891 --> 01:48:37,792
这样的话tmp就足够大，从而不会出现那个指数位太远，差的太远，导致精度误差的问题

942
01:48:37,999 --> 01:48:43,999
它是精度上的提升，不是性能上的提升

943
01:48:43,999 --> 01:48:50,500
但我们最好也要做一做。嗯，然后这里是全部这节课的总结

944
01:48:50,500 --> 01:48:54,999
首先函数尽量写在同一个文件里，不需要inline

945
01:48:54,999 --> 01:49:02,999
你写同一个文件就行了，然后使避免for循环里调用，不在同一个文件的函数

946
01:49:04,792 --> 01:49:10,999
然后是只要非const 的指针尽量去加上__restrict ，表明不会出现指针别名

947
01:49:10,999 --> 01:49:14,999
然后SOA往往是比AOS更高效的

948
01:49:14,999 --> 01:49:24,375
然后如果你实在要AOS，可以试试看对齐到16或者64字节，16是SIMD宽度

949
01:49:24,375 --> 01:49:27,083
64是缓存行宽度，

950
01:49:27,107 --> 01:49:34,999
然后把你的代码写的简单点，让编译器去看懂，你搞复杂化，它看不懂，它就没法优化

951
01:49:34,999 --> 01:49:43,724
然后就是有时候我们会出现指针别名，这时候可以用omp simd强制它用simd优化，

952
01:49:43,748 --> 01:49:52,999
然后循环中的不变量编译器有时候能够优化成功，包括if的判断，有时候能优化成功

953
01:49:52,999 --> 01:49:57,999
如果你不确定，最好还是手动把它挪到外面来吧

954
01:49:58,999 --> 01:50:05,792
然后如果你的循环体很小，可以用unroll展开，看看有没有性能提升

955
01:50:05,792 --> 01:50:14,375
然后对于GCC编译器可以加上这两个，让它快两倍甚至4倍都有可能，明白吗？

956
01:50:15,999 --> 01:50:35,999
为啥加个括号?没看懂。这个为啥加括号?不管了，总之就是这几个手法，这次作业你也会用

957
01:50:35,999 --> 01:50:40,167
,然后就是在Cmake 里怎么开这些开关

958
01:50:40,167 --> 01:50:42,038
首先是-O3 ，

959
01:50:42,062 --> 01:50:48,318
这个默认的CMAKE_BUILD_TYPE是debug ，它会生成一些调试，

960
01:50:48,342 --> 01:50:52,999
但是它的优化就会被关掉，然后也可以开启O3

961
01:50:52,999 --> 01:50:56,734
就是用release模式，它就相当于O3了，

962
01:50:56,758 --> 01:51:05,542
而且在MSVC上也会替换为相应的那个flag，还有fopenmp

963
01:51:05,542 --> 01:51:11,332
这因为这个fopenmp是只针对GCC的开启方式，

964
01:51:11,356 --> 01:51:19,500
微软的可能不一样，所以可以使用这种通用的方式来开启它

965
01:51:19,500 --> 01:51:21,915
它是做成了一个库的形式，

966
01:51:21,939 --> 01:51:29,999
然后ffast-math 和march ，这个好像是没办法，就是变成一个跨平台的

967
01:51:29,999 --> 01:51:35,999
你只能就针对GCC开这两个，感谢你的观看

968
01:51:35,999 --> 01:51:45,999
这个作业还在做啊，我还没提交上去，就是等会儿我会把。。。安卓上好像是出错了

969
01:51:46,999 --> 01:51:54,788
我怎么以为是O3 ，就是我上次试过在安卓上搞openmp，结果出错了

970
01:51:54,812 --> 01:51:56,999
我先停一下