05.srt

1
00:00:00,022 --> 00:00:04,758
【字幕生成: 奔崩 字幕校对: 奔崩】
(放~片~头)

2
00:00:04,813 --> 00:00:06,520
Hello 大家好

3
00:00:06,560 --> 00:00:08,560
我是月入 2800

4
00:00:08,560 --> 00:00:10,080
每天笑哈哈的 ZOMI

5
00:00:10,120 --> 00:00:13,520
今天我们还是来到 AI 编译器的后端优化

6
00:00:13,560 --> 00:00:16,160
不过今天的内容枯燥和无聊

7
00:00:16,160 --> 00:00:19,760
就讲讲我们指令还有存储的优化的方式

8
00:00:19,800 --> 00:00:23,920
现在我们还是在算子调度优化这个内容里面

9
00:00:23,960 --> 00:00:25,200
而算子调度优化

10
00:00:25,320 --> 00:00:28,600
其实我们之前已经讲了我们的循环优化

11
00:00:28,680 --> 00:00:32,240
今天重点的来了解一下向量化、张量化

12
00:00:32,240 --> 00:00:36,160
还有访存延迟和存储分配这 4 个内容

13
00:00:37,520 --> 00:00:40,000
在指令优化 instruction optimization

14
00:00:40,000 --> 00:00:41,760
里面的第一个重要的内容

15
00:00:41,760 --> 00:00:43,040
就是向量化

16
00:00:43,080 --> 00:00:44,600
vectorization

17
00:00:44,640 --> 00:00:46,080
我的英语不一定读的准

18
00:00:46,080 --> 00:00:47,000
但是读的不准

19
00:00:47,000 --> 00:00:48,400
大家也不要吐槽

20
00:00:48,720 --> 00:00:50,560
我们以下面这个图为例

21
00:00:50,560 --> 00:00:51,960
假设我现在一次过

22
00:00:52,080 --> 00:00:54,440
我想计算内存里面的 4 个字节

23
00:00:54,440 --> 00:00:56,200
或者 4 个单位的数据

24
00:00:56,240 --> 00:00:58,680
我首先从内存里面的低位开始读取

25
00:00:58,680 --> 00:01:00,760
一次过读取 4 个数据出来

26
00:01:00,760 --> 00:01:02,920
接着我再从下一个低位开始

27
00:01:02,920 --> 00:01:04,960
继续读取 4 个数据出来

28
00:01:04,960 --> 00:01:07,880
跟之前的 4 个数据一起去计算

29
00:01:07,880 --> 00:01:09,720
不断的循环这种加的操作

30
00:01:09,880 --> 00:01:12,760
这种方式也叫做向量化的一种方式

31
00:01:12,760 --> 00:01:16,080
就是一次过读取或者处理多个数据

32
00:01:16,360 --> 00:01:18,080
现在我们看一个具体的例子

33
00:01:18,080 --> 00:01:20,400
在没有进行任何向量化的时候

34
00:01:20,400 --> 00:01:22,320
第 2 到第 5 行的代码里面

35
00:01:22,440 --> 00:01:25,720
主要是对 a[i]这个数组进行求和

36
00:01:25,720 --> 00:01:29,240
那 a[i]这个数组它有一个 N 个元素

37
00:01:29,240 --> 00:01:30,480
通过 for 循环

38
00:01:30,480 --> 00:01:32,680
a[i]对 sum 进行累加

39
00:01:32,680 --> 00:01:34,320
求得 a[i]这个数组的和

40
00:01:34,320 --> 00:01:36,920
现在我们向量化之后可以看到

41
00:01:37,040 --> 00:01:39,400
这里面用了 CPU 的向量化的指令

42
00:01:39,400 --> 00:01:41,320
然后去定义我们 double<4>一个

43
00:01:41,320 --> 00:01:43,680
vec_sum 等于有 4 个数据

44
00:01:43,680 --> 00:01:46,040
接着我们在迭代的时候去声明

45
00:01:46,040 --> 00:01:46,960
我的 double<4>

46
00:01:47,160 --> 00:01:49,760
同样用 add<4>进行一个累加

47
00:01:50,000 --> 00:01:51,840
下面这种方式就是 CPU 里面

48
00:01:51,840 --> 00:01:54,120
比较经典的一种向量化的方式

49
00:01:55,720 --> 00:01:57,000
了解完向量化之后

50
00:01:57,000 --> 00:01:59,120
我们看一下张量化

51
00:01:59,120 --> 00:02:00,720
Tensorization

52
00:02:00,720 --> 00:02:02,320
张量化这个概念

53
00:02:02,520 --> 00:02:04,920
是随着我们的神经网络

54
00:02:05,120 --> 00:02:07,000
和随着新的 AI 芯片

55
00:02:07,000 --> 00:02:08,720
和新的硬件架构

56
00:02:08,720 --> 00:02:10,000
慢慢的出现的

57
00:02:10,920 --> 00:02:11,560
例如

58
00:02:12,000 --> 00:02:14,000
在 GPU 的 Volta 架构里面

59
00:02:14,160 --> 00:02:16,280
一个 SM 有多个 CUDA core

60
00:02:16,280 --> 00:02:18,840
还有多个 Tensor core 去组成

61
00:02:18,840 --> 00:02:20,920
我们看看左下角的这个图

62
00:02:21,240 --> 00:02:23,280
这里面就有对应的 Tensor core

63
00:02:23,280 --> 00:02:25,280
还有很多 CUDA core

64
00:02:25,520 --> 00:02:28,160
这些 core 都是我们的计算单元

65
00:02:28,520 --> 00:02:29,200
而 Tensor core

66
00:02:29,440 --> 00:02:30,840
最主要的就是用来做

67
00:02:30,840 --> 00:02:32,560
我们的张量化的计算

68
00:02:32,560 --> 00:02:34,000
就是 Tensorization 的计算

69
00:02:35,000 --> 00:02:35,560
下面这个图

70
00:02:35,720 --> 00:02:37,520
就是我们具体张量化的一个计算

71
00:02:37,520 --> 00:02:39,000
我们有一个矩阵 A

72
00:02:39,000 --> 00:02:40,240
可能有一个矩阵 B

73
00:02:40,440 --> 00:02:42,280
矩阵 A 跟 B 进行相乘

74
00:02:42,760 --> 00:02:44,240
然后再加上一个矩阵

75
00:02:44,520 --> 00:02:46,160
这种方式是非常符合

76
00:02:46,160 --> 00:02:47,760
我们神经网络的 GEMM

77
00:02:47,760 --> 00:02:49,560
或者卷积的计算方式

78
00:02:49,560 --> 00:02:51,000
所以单独把它做成一种

79
00:02:51,000 --> 00:02:51,840
硬件的架构

80
00:02:51,840 --> 00:02:53,000
或者硬件的 core

81
00:02:53,280 --> 00:02:54,160
对我们的神经网络

82
00:02:54,160 --> 00:02:55,560
进行特殊的加速

83
00:02:56,920 --> 00:02:57,880
现在我们来看看

84
00:02:57,880 --> 00:02:59,920
一些主流的厂商是怎么做的

85
00:02:59,920 --> 00:03:01,600
像现在的 CPU

86
00:03:01,600 --> 00:03:03,120
或者 GPU 那些厂商

87
00:03:03,560 --> 00:03:05,760
说白了就是英特尔和英伟达

88
00:03:05,760 --> 00:03:07,280
都会提供专门用于

89
00:03:07,280 --> 00:03:09,280
张量加速的一些指令

90
00:03:09,560 --> 00:03:11,080
英伟达里面就提供了

91
00:03:11,080 --> 00:03:12,560
针对 Tensor core 的指令

92
00:03:12,560 --> 00:03:14,400
而英特尔提出了自己的 VN

93
00:03:15,160 --> 00:03:16,280
有了这些指令之后

94
00:03:16,480 --> 00:03:17,080
像英伟达

95
00:03:17,080 --> 00:03:18,160
它就推出了它的

96
00:03:18,160 --> 00:03:19,480
cuBLAS 还有 cuDNN

97
00:03:19,840 --> 00:03:20,480
里面的算子

98
00:03:20,640 --> 00:03:22,080
就使用了张量和指令

99
00:03:22,080 --> 00:03:23,000
来去计算的

100
00:03:23,000 --> 00:03:24,160
还有英伟达的 oneDNN

101
00:03:24,160 --> 00:03:24,960
里面也使用了

102
00:03:24,960 --> 00:03:26,240
它自己的张量和

103
00:03:26,240 --> 00:03:27,960
和张量指令来去计算的

104
00:03:28,280 --> 00:03:30,240
但是有一个很严重的问题

105
00:03:30,240 --> 00:03:32,440
就是当模型出现了新的算子

106
00:03:32,680 --> 00:03:34,160
或者需要对我们的张量

107
00:03:34,160 --> 00:03:35,400
进行进一步的

108
00:03:35,400 --> 00:03:36,800
提高这些性能的时候

109
00:03:37,160 --> 00:03:38,320
那我们就不可能

110
00:03:38,320 --> 00:03:39,640
局限性的去用

111
00:03:39,640 --> 00:03:40,880
像英伟达提出的

112
00:03:40,880 --> 00:03:42,080
cuBLAS 或者 cuDNN

113
00:03:42,320 --> 00:03:43,040
因为我们可以知道

114
00:03:43,040 --> 00:03:44,200
cuDNN 其实它现在

115
00:03:44,480 --> 00:03:45,640
只有 200 多个算子

116
00:03:45,880 --> 00:03:46,720
200 多个算子

117
00:03:46,720 --> 00:03:47,920
是没有办法覆盖掉

118
00:03:47,920 --> 00:03:49,560
我们所有神经网络

119
00:03:49,560 --> 00:03:50,600
或者所有新的

120
00:03:50,600 --> 00:03:52,040
AI 算法的场景

121
00:03:52,360 --> 00:03:54,320
这个时候局限性就会出现

122
00:03:54,320 --> 00:03:55,920
所以我们需要 AI 编译器

123
00:03:56,200 --> 00:03:57,720
去提供张量化

124
00:03:58,040 --> 00:03:58,800
Tensorization 的

125
00:03:58,800 --> 00:04:00,640
一种指令或者调度语言

126
00:04:01,800 --> 00:04:03,480
下面我们来看看几个问题

127
00:04:03,480 --> 00:04:04,720
首先就是新的

128
00:04:04,880 --> 00:04:06,440
刚才我们也简单的提了

129
00:04:06,680 --> 00:04:08,880
现在我们系统的来看一看

130
00:04:09,160 --> 00:04:10,400
首先就是新的硬件

131
00:04:10,400 --> 00:04:11,520
会带来非常多的

132
00:04:11,520 --> 00:04:13,160
超越向量化的一些运算

133
00:04:13,400 --> 00:04:15,320
就是我们刚才提到了向量化

134
00:04:15,640 --> 00:04:16,960
后来有了张量化

135
00:04:16,960 --> 00:04:18,960
是因为我们新的硬件体系

136
00:04:18,960 --> 00:04:20,080
和新的领域知识

137
00:04:20,240 --> 00:04:22,400
使得我们需要有新的指令集

138
00:04:22,400 --> 00:04:23,600
就是张量的指令集

139
00:04:23,840 --> 00:04:25,840
第二个就是张量的计算单元

140
00:04:26,160 --> 00:04:27,360
输入都是多维的

141
00:04:27,360 --> 00:04:28,080
因为 Tensor

142
00:04:28,080 --> 00:04:30,040
它本来天然就有多维的

143
00:04:30,040 --> 00:04:32,080
可能在处理一些图像的时候

144
00:04:32,080 --> 00:04:34,120
我们需要用到四维的数据

145
00:04:34,360 --> 00:04:36,680
处理点云渲染三维的物体的时候

146
00:04:36,680 --> 00:04:38,600
我们可能会需要五维的数据

147
00:04:38,880 --> 00:04:40,120
自然语言场景里面

148
00:04:40,280 --> 00:04:42,320
可能还会做一个变长

149
00:04:42,320 --> 00:04:44,520
就是长度会不断的去变化

150
00:04:44,760 --> 00:04:45,880
并且都会有一些

151
00:04:45,880 --> 00:04:48,240
不同的数据布局的定义

152
00:04:49,120 --> 00:04:51,560
第三个就是新的 AI 加速器

153
00:04:51,920 --> 00:04:53,560
谷歌它自己就做了 TPU

154
00:04:53,560 --> 00:04:54,960
华为自己做了昇腾

155
00:04:55,160 --> 00:04:57,280
都会有我们自己的一个张量的指令

156
00:04:57,280 --> 00:04:59,200
所以说很多新的加速器

157
00:04:59,200 --> 00:05:01,080
都会有自己的指令出现

158
00:05:01,560 --> 00:05:03,440
面对上面的这些情况下

159
00:05:03,720 --> 00:05:06,880
像 TVM 就提出了一种张量化的方式

160
00:05:06,880 --> 00:05:08,200
将硬件指令的接口

161
00:05:08,360 --> 00:05:09,320
还有调度分开

162
00:05:09,320 --> 00:05:11,240
生成新的硬件接口

163
00:05:11,720 --> 00:05:14,160
当然除了 TVM 提供的这种方式

164
00:05:14,160 --> 00:05:15,880
其实很多 AI 厂商

165
00:05:16,160 --> 00:05:17,120
提供一些新的指令

166
00:05:17,120 --> 00:05:19,400
或者一些新的 AI 编辑器的方式出来

167
00:05:21,760 --> 00:05:23,400
了解完向量化和张量化

168
00:05:23,400 --> 00:05:25,400
这两个指令优化之后的

169
00:05:25,400 --> 00:05:28,920
我们现在来看看两个非常重要的话题

170
00:05:28,920 --> 00:05:30,360
就是存储优化

171
00:05:30,360 --> 00:05:32,120
Memory Optimization

172
00:05:32,120 --> 00:05:33,800
Memory Optimization 里面

173
00:05:33,920 --> 00:05:36,040
第一个就是访存的延迟

174
00:05:36,040 --> 00:05:37,200
Latency Hiding

175
00:05:37,200 --> 00:05:38,840
这里面的访存延迟

176
00:05:38,840 --> 00:05:40,240
更多的是指 指令

177
00:05:40,240 --> 00:05:42,360
或者内存的访存延迟

178
00:05:42,640 --> 00:05:45,240
这里面我们看看访存延迟的一个定义

179
00:05:45,600 --> 00:05:46,800
访存延迟主要是指

180
00:05:46,800 --> 00:05:50,080
将内存的操作和计算进行重叠

181
00:05:50,080 --> 00:05:51,920
我们来看看下面的图

182
00:05:51,920 --> 00:05:53,440
在 AI 进行训练的时候

183
00:05:53,600 --> 00:05:55,440
我们会有大量的核或者线程

184
00:05:55,760 --> 00:05:57,240
去执行我们的算子

185
00:05:57,240 --> 00:05:58,600
或者执行我们的计算

186
00:05:58,600 --> 00:05:59,920
但是我们的计算

187
00:05:59,920 --> 00:06:02,000
是严重依赖于我们的 Memory 的

188
00:06:02,000 --> 00:06:03,760
我们有内存有数据了

189
00:06:03,760 --> 00:06:04,760
才能够去计算

190
00:06:05,080 --> 00:06:05,720
计算完之后

191
00:06:05,800 --> 00:06:07,280
我们会把数据的结果

192
00:06:07,280 --> 00:06:09,400
存回到我们的 Memory 里面

193
00:06:09,840 --> 00:06:12,600
这个时候我们内存跟计算就会重叠

194
00:06:12,600 --> 00:06:14,520
我们能不能做一些虚拟线程

195
00:06:14,520 --> 00:06:16,120
或者多个线程的时候

196
00:06:16,200 --> 00:06:19,080
把我们的内存的操作和计算进行重叠

197
00:06:19,360 --> 00:06:21,080
最大限度的提高我们内存

198
00:06:21,080 --> 00:06:22,520
和计算资源的利用率

199
00:06:22,920 --> 00:06:26,360
这个就是访存延迟需要去解决的问题

200
00:06:27,640 --> 00:06:30,560
下面我们来看看 CPU GPU 还有 NPU

201
00:06:30,760 --> 00:06:32,520
它们针对访存延迟

202
00:06:32,760 --> 00:06:34,960
都有自己不同的处理方式

203
00:06:35,360 --> 00:06:36,960
首先就是 CPU

204
00:06:37,240 --> 00:06:39,120
CPU 比较成熟

205
00:06:39,440 --> 00:06:41,880
CPU 可以通过多线程或者多进程

206
00:06:42,160 --> 00:06:45,760
还有硬件的隐式的数据预取去实现

207
00:06:46,320 --> 00:06:48,560
第二个我们来看看 GPU

208
00:06:49,720 --> 00:06:52,240
GPU 更多的是依赖于 wrap Schedule

209
00:06:52,240 --> 00:06:55,440
对我们的多线程或者 SM 进行一个管理

210
00:06:55,640 --> 00:06:57,480
还有上下文快速的切换

211
00:06:57,480 --> 00:07:00,200
这种方式去掩盖我们的访存延迟

212
00:07:00,560 --> 00:07:03,360
像 NPU TPU 这种新的 AI 加速器

213
00:07:03,560 --> 00:07:07,200
大部分都会采用解耦访问和执行

214
00:07:07,200 --> 00:07:10,480
就是 DAE 的一个硬件架构去实现的

215
00:07:10,640 --> 00:07:13,080
DAE 是什么我们后面将会展开

216
00:07:14,080 --> 00:07:17,720
现在我们来看看 GPU 的一个访存延迟

217
00:07:17,720 --> 00:07:18,920
到底是怎么实现的

218
00:07:19,120 --> 00:07:21,800
右边的这个就是 GPU 的整体的架构

219
00:07:21,800 --> 00:07:23,640
里面的 cache 分开三层

220
00:07:23,640 --> 00:07:24,440
第一个是 DRAM

221
00:07:24,440 --> 00:07:26,000
第二个是 L2 的 cache

222
00:07:26,000 --> 00:07:27,600
最后一个是 L1 的 cache

223
00:07:27,600 --> 00:07:30,000
L1 的 cache 就离我们的 CUDA Core

224
00:07:30,000 --> 00:07:31,840
或者我们的 Tensor Core 非常近了

225
00:07:31,840 --> 00:07:35,480
而 Tensor Core 就是具体计算的单元

226
00:07:35,480 --> 00:07:37,480
而具体计算单元到内存之间

227
00:07:37,640 --> 00:07:39,040
它有个 Wrap Schedule

228
00:07:39,240 --> 00:07:42,040
专门针对线程进行管理的 Schedule

229
00:07:42,640 --> 00:07:44,160
下面这个就是 Wrap Schedule

230
00:07:44,160 --> 00:07:46,640
跟我们具体的指令之间的一个关系

231
00:07:46,640 --> 00:07:48,560
Wrap Schedule 就会对我们的指令

232
00:07:48,680 --> 00:07:50,120
做好分发和预分配

233
00:07:50,120 --> 00:07:52,480
然后给我们的 Instruction Dispatch Unit

234
00:07:52,480 --> 00:07:54,760
接着 IDU 就会把具体的线程

235
00:07:54,760 --> 00:07:57,000
分发到不同的 worker 上面去执行

236
00:07:57,000 --> 00:07:59,560
或者分发到不同的 Wrap 上面去执行的

237
00:08:00,560 --> 00:08:02,560
假设我们现在有 4 个 Wrap

238
00:08:02,560 --> 00:08:04,720
然后每个 Wrap 都有一个指令

239
00:08:04,720 --> 00:08:07,400
而 Instruction3 就是我们的 Wrap0

240
00:08:07,400 --> 00:08:09,880
现在是一个读数据的过程当中

241
00:08:09,880 --> 00:08:11,800
如果这个 Wrap 在读数据

242
00:08:11,880 --> 00:08:14,160
就会导致我们整个系统的阻塞

243
00:08:14,160 --> 00:08:15,560
或者我们的线程的阻塞

244
00:08:15,560 --> 00:08:17,960
这个时候 Wrap1 或者 Instruction2

245
00:08:17,960 --> 00:08:19,280
就会去执行 Wrap2

246
00:08:19,280 --> 00:08:21,320
Instruction1 也会去执行

247
00:08:21,320 --> 00:08:23,440
所以说 Wrap1 和 Wrap2 的执行

248
00:08:23,440 --> 00:08:25,680
是不会因为 Wrap0 的阻塞

249
00:08:25,880 --> 00:08:27,640
GPU 就通过 Wrap Schedule

250
00:08:27,640 --> 00:08:28,640
Wrap 的控制

251
00:08:28,640 --> 00:08:31,320
来去解决我们访存延迟的问题

252
00:08:33,080 --> 00:08:35,240
下面我们来看看 DAE

253
00:08:35,240 --> 00:08:38,720
解耦访问和执行的一个这样的架构

254
00:08:38,720 --> 00:08:40,840
什么为之解耦访问执行呢

255
00:08:40,840 --> 00:08:42,440
其实比较明确

256
00:08:42,440 --> 00:08:44,680
就是把访问跟执行

257
00:08:44,680 --> 00:08:47,160
访问内存跟具体执行计算

258
00:08:47,160 --> 00:08:48,320
分开过来

259
00:08:48,320 --> 00:08:50,200
把内存访问的单元 MAU

260
00:08:50,200 --> 00:08:51,720
跟我们的管道分离

261
00:08:51,720 --> 00:08:53,800
那执行处理器就是我们的 EP

262
00:08:53,800 --> 00:08:56,760
由直接寄存器访问和直接缓存访问

263
00:08:56,760 --> 00:08:58,280
用于来管理寄存器

264
00:08:58,280 --> 00:09:00,880
缓存和内存之间的一个数据传输

265
00:09:00,880 --> 00:09:02,160
说的很复杂

266
00:09:02,160 --> 00:09:03,920
还是回到我们这句话

267
00:09:03,920 --> 00:09:07,560
解耦访问内存跟执行计算进行分开

268
00:09:07,560 --> 00:09:10,320
这个就是我们大部分 NPU 和 TPU

269
00:09:10,360 --> 00:09:12,040
大量新涌现的 AI 加速器

270
00:09:12,040 --> 00:09:13,600
所采用的一种方式

271
00:09:14,120 --> 00:09:15,920
TPU 里面就采用一种技术

272
00:09:15,920 --> 00:09:17,160
叫做虚拟线程

273
00:09:17,160 --> 00:09:18,440
通过这种虚拟线程

274
00:09:18,440 --> 00:09:19,640
把并行的一些程序

275
00:09:19,640 --> 00:09:22,000
转换成为单个指令流

276
00:09:22,000 --> 00:09:23,240
这种方式的好处

277
00:09:23,240 --> 00:09:25,200
就是我们的 Pipeline 是比较明确的

278
00:09:25,200 --> 00:09:27,080
可以通过软件进行控制

279
00:09:27,080 --> 00:09:29,200
但是问题也是比较明显

280
00:09:29,200 --> 00:09:30,800
硬件的执行的正确顺序

281
00:09:30,800 --> 00:09:32,600
需要通过软件进行控制

282
00:09:32,600 --> 00:09:35,200
而且需要通过低级的同步来去实现的

283
00:09:35,200 --> 00:09:36,600
实现的算法好和坏

284
00:09:36,600 --> 00:09:39,160
就决定了访存延迟的性能

285
00:09:41,320 --> 00:09:43,840
接着我们来到内存优化的第二个点

286
00:09:43,840 --> 00:09:45,320
就是内存分配了

287
00:09:45,320 --> 00:09:47,920
我们要回顾一下几个变量

288
00:09:47,920 --> 00:09:49,480
第一个就是局部变量

289
00:09:49,480 --> 00:09:51,040
第二个是全局变量

290
00:09:51,040 --> 00:09:52,560
第三个是堆变量

291
00:09:53,000 --> 00:09:54,600
（战 术 变 声）
诶 ZOMI 老师你好啊

292
00:09:55,160 --> 00:09:57,720
局部变量和全局变量我听得多

293
00:09:57,720 --> 00:09:59,280
啥是堆变量呢

294
00:10:00,360 --> 00:10:02,000
这个问题问得非常有意思

295
00:10:02,000 --> 00:10:04,320
我们现在都是 C 或者 C++

296
00:10:04,680 --> 00:10:07,480
现在我们都是 C 或者 C++作为例子

297
00:10:07,480 --> 00:10:09,720
现在我们看看每一个的定义

298
00:10:10,120 --> 00:10:12,960
局部变量主要是指我们定义的一些普通变量

299
00:10:12,960 --> 00:10:16,560
那普通变量就是 int i, int j, int zomi[10]

300
00:10:16,880 --> 00:10:18,440
编译器会在我们的 CPU

301
00:10:18,440 --> 00:10:21,080
或者在我们的系统里面的内存占空间

302
00:10:21,080 --> 00:10:24,400
为我们这些变量分配一段内存的

303
00:10:24,400 --> 00:10:26,400
那这种就叫做局部变量

304
00:10:26,400 --> 00:10:29,120
那接下来我们来看看什么叫全局变量

305
00:10:29,120 --> 00:10:30,400
全局变量有两种

306
00:10:30,400 --> 00:10:31,480
一种是 global 的

307
00:10:31,480 --> 00:10:32,800
一种 static

308
00:10:32,800 --> 00:10:36,520
那 global 就是像这种是全局变量 int x 和 y

309
00:10:36,800 --> 00:10:38,840
在我们的函数外部去声明的

310
00:10:39,280 --> 00:10:40,400
另外一种静态的变量

311
00:10:40,560 --> 00:10:42,400
是我们明确声明 static 的

312
00:10:42,960 --> 00:10:45,160
编译器会在内存的静态存储区

313
00:10:45,320 --> 00:10:47,440
去分配对应的内存空间的

314
00:10:47,880 --> 00:10:50,400
那最后一个就是堆变量了

315
00:10:50,400 --> 00:10:52,120
堆变量其实我们经常用

316
00:10:52,120 --> 00:10:54,160
只是可能很少这么去提

317
00:10:54,160 --> 00:10:56,360
开发者使用 new 或者 malloc

318
00:10:56,720 --> 00:10:59,200
在堆上面去申请的一段内存空间

319
00:10:59,200 --> 00:11:00,520
我们叫做堆变量

320
00:11:00,520 --> 00:11:02,680
那所以 C 或者 C++里面

321
00:11:02,800 --> 00:11:04,520
会有三种不同的变量

322
00:11:05,440 --> 00:11:07,480
而实际上对于内存空间

323
00:11:07,560 --> 00:11:08,720
我们传统的编译器

324
00:11:08,840 --> 00:11:10,760
就会把我们的整体的内存块

325
00:11:10,760 --> 00:11:12,080
划分为不同的段

326
00:11:12,080 --> 00:11:15,360
来提供给我们不同的一些程序

327
00:11:15,640 --> 00:11:16,920
去访问我们的内存的

328
00:11:17,080 --> 00:11:19,960
例如这里面就分为静态的存储区

329
00:11:19,960 --> 00:11:21,200
还有堆的存储区

330
00:11:21,200 --> 00:11:23,480
还有栈还有代码区和用户区

331
00:11:23,760 --> 00:11:25,680
代码区和用户区我们可以放开

332
00:11:25,680 --> 00:11:28,680
而我们刚才讲到的几种内存的分配变量

333
00:11:28,680 --> 00:11:29,960
就是我们的栈堆

334
00:11:30,280 --> 00:11:31,760
还有我们的静态存储空间

335
00:11:31,760 --> 00:11:34,520
而存储的方式也是按低位到高位的

336
00:11:35,200 --> 00:11:37,000
我们在写 CUDA 代码的时候

337
00:11:37,120 --> 00:11:38,120
会通过 Workspace

338
00:11:38,120 --> 00:11:39,240
然后去开辟一个

339
00:11:39,600 --> 00:11:41,200
就会开辟一个 Workspace 的空间

340
00:11:41,200 --> 00:11:42,800
这种就是告诉我们的系统

341
00:11:43,080 --> 00:11:44,360
到底要给 GPU 的显存

342
00:11:44,360 --> 00:11:46,080
怎么去分配我们的内存空间呢

343
00:11:46,560 --> 00:11:47,320
刚才这种方式

344
00:11:47,440 --> 00:11:49,360
更多的是传统 CPU 的方式

345
00:11:49,360 --> 00:11:51,200
和传统编译器结合的方式

346
00:11:51,680 --> 00:11:53,400
在我们神经网络经常跑的 GPU

347
00:11:53,400 --> 00:11:54,960
或者 AI 加速芯片里面

348
00:11:55,120 --> 00:11:57,120
内存分配就可能更加复杂了

349
00:11:57,360 --> 00:11:59,600
因为这里面又有了 L1 的 shared memory

350
00:11:59,600 --> 00:12:01,120
还有 L2 的 local memory

351
00:12:01,600 --> 00:12:03,120
还有跟系统交互的 DRAM

352
00:12:03,640 --> 00:12:05,040
面向不同的 AI 加速芯片

353
00:12:05,040 --> 00:12:06,280
内存的分配的方式

354
00:12:06,280 --> 00:12:07,640
其实是越来越复杂的

355
00:12:08,080 --> 00:12:08,920
如果我们全部的

356
00:12:08,920 --> 00:12:10,040
通过人工的去控制

357
00:12:10,040 --> 00:12:10,920
写 CUDA 去控制

358
00:12:10,920 --> 00:12:12,160
其实对我们工程师

359
00:12:12,600 --> 00:12:13,720
对 kernel 的开发者来说

360
00:12:13,720 --> 00:12:14,760
要求是非常高的

361
00:12:14,760 --> 00:12:15,520
所以这些工作

362
00:12:15,840 --> 00:12:18,920
我们都会交给 AI 编译器去解决

363
00:12:20,680 --> 00:12:21,000
好了

364
00:12:21,000 --> 00:12:21,640
到目前为止

365
00:12:21,800 --> 00:12:24,240
我已经给大家汇报完

366
00:12:24,240 --> 00:12:26,840
整个算子调度的一些优化的方法

367
00:12:27,120 --> 00:12:28,080
从循环的优化

368
00:12:28,080 --> 00:12:28,720
各种 loop

369
00:12:28,720 --> 00:12:29,880
到我们的指令优化

370
00:12:29,880 --> 00:12:30,760
向量张量

371
00:12:30,760 --> 00:12:33,040
到现在最后的一个存储优化

372
00:12:34,080 --> 00:12:35,800
访存的延迟和存储的分配

373
00:12:35,960 --> 00:12:37,840
有了这些基本的知识概念之后

374
00:12:38,160 --> 00:12:39,600
我们将会在下一节里面

375
00:12:39,600 --> 00:12:40,560
去给大家去分享

376
00:12:40,840 --> 00:12:41,400
Auto-Tuning

377
00:12:41,680 --> 00:12:43,520
怎么把算子调度这些优化

378
00:12:43,920 --> 00:12:45,800
真正的让它自动化起来

379
00:12:46,080 --> 00:12:47,080
然后还有 Polyhedral

380
00:12:47,360 --> 00:12:48,520
怎么结合起来

381
00:12:49,960 --> 00:12:50,680
卷的不行了

382
00:12:50,680 --> 00:12:51,480
卷的不行了

383
00:12:51,480 --> 00:12:52,960
记得一键三连加关注

384
00:12:53,520 --> 00:12:54,680
所有的内容都会开源

385
00:12:54,680 --> 00:12:56,320
在下面这条链接里面

386
00:12:57,040 --> 00:12:57,640
拜了个拜