标签：cpufp AVX aws 编程并行 ymm12 GFLOPS CPU FMA

云计算-CPU 并行编程-科研路-电动汽车分析

参考文献链接

https://mp.weixin.qq.com/s/TSsmcW2i8so_dZ86TRKn0A

https://mp.weixin.qq.com/s/19vs_187sVEpW7c4L2aT5w

https://mp.weixin.qq.com/s/aXjJrJCphzLcrOB5b5OJHA

https://mp.weixin.qq.com/s/cRazbzhrICgkbB5H7FCf_w

reinvent 2022:云计算巨头技术创新进入瓶颈期?

前言

aws reinvent 2022已经结束好几天了，笔者最近抽出了一点时间将相关的topics浏览了一下。唯一的感受就是aws 技术上的创新似乎已经进入瓶颈期。如果说前几届reinvent创新是从0到1，那么今年的相关创新更多是从1到n的横向扩展。下面笔者会按照相关的时间线给大家一一来介绍一下笔者眼中的一些创新技术点。

Nitro system v5

如果关注云计算的同学想必对nitro并不陌生，这是每一届reinvent都必谈的话题，国内也有众多的追随者。今年nitro已经迭代到了第5代，关于前4代我们可以从下面这张图获取一些信息

图1 nitro time line

需要说明的是图中GBPS应该是Gbps(从其他子topic里面得到确认)，可能各位看官也注意到nitrio 从v1到v4它的pps跟国内动不动几十MPPS相比差距还比较大，但是从实际的应用来看图上展示的pps是足够用了。接下来我们看一下nitro v5的一些相关参数，具体如下：

图2 nitro v5

从图2来看，nitro 第5代的相关参数和性能可以总结如下：1)支持网络、内存、pcie链路的全加密，支持PCIe gen5和DDR5；2)220亿个transistors性能更强；3）pps上增加了60%，同时latency降低了30%。目前，在硬件配置上国内的追随者们还没有一家能够追平nitro v5。当然这里面不是技术的问题，更多的是成本上的考虑。而AWS nitro一方面是基于ASIC另一方面基于aws巨大的用户体量，因此nitro 可以把成本降的比较低，同时性能上也要比国内一众基于fpga实现的dpu要高很多。

Graviton3E

aws 基于ARM的自研cpu，graviton系列是从2018年开始的，截止到目前已经迭代到了第三代。笔者之前也写Graviton3的文章——深入解读aws graviton3 如果感兴趣大家可以再温习一下，这里再带着大家回顾一下Graviton3的相关参数

图3 Gravtion3 cpu 性能加强

从上面可以看到Graviton3比起Graviton2在相关方面都进行了加强，具体如下：1)指令fetch上由4-wide提升到了8-wide，也就是说每个cycle能够fetch的指令是graviton2的两倍；2)同样译码上最大也提升了2位，由原来的4-wide提升到5~8wide；3)instruction windows上也扩大了2倍，这个是跟上面的取指、译码是相呼应的；4)SIMD、内存、矩阵运算单元也都提升了2倍，主要跟graviton3主打机器学习、hpc场景有关。回顾完了graviton3，我们接下来看一下Graviton3E，相关的参数如下图所示：

图4 Graviton3E

从图4可以看到Graviton3E主要是在SIMD上进行了增强(还是在主打HPC场景)，有相关的测试上性能要比Graviton3 提升15%~30%左右。

这里需要另外说明的是虚拟化的场景下Graviton系列都是单numa且没有SMT的，另外从Graviton2开始支持虚拟中断直通也就是说至少是支持gicv4的。目前国内使用的安培或者华为鲲鹏在虚拟化场景下到目前为止还都不支持虚拟中断直通。

图5 Graviton guest interrupt passthrough

AWS Trainium&Inferentia

这个是aws在机器学习方面自研的训练和推理芯片，当然AWS inf1早在2019年就已经release出来的，而aws Trainium 最早是在2020 reinvent大会上 expose出来。当时规划是在2021年可以跟用户见面，但是只到2022年的10月份才正式推出(这里面估计跟疫情供应链紧张有一定的关系)。坦诚地讲，自研机器学习芯片进入机器学习生态的最大问题就是如何跟现有的机器学习框架进行无缝对接。大家都比较清楚NV在这方面凭借着cuda牢牢控制着整个机器学习端到端的生态，这也不枉老黄在cuda生态上扔出去的上百亿美金。而为了解决这个问题，AWS推出了自家的类cuda的Neuron SDK，据说是用户对现在的应用只需要少量的修改就可以使用。目前，Neuron 软件包已经集成到PyTorch和TensorFlow等主流的机器学习框架当中

图6 aws inf and trin with Neuron

下面我们重点来看一下Trainium相关性能和具体参数，具体如下图所示：

图7 aws Trn1

机器学习workload对内存带宽和网络带宽都有比较高的要求，从上面可以看到Trn1在内存带宽上可以达到13.1TB/s，在网络上可以支持到800~1600Gbps。另外，不知道各位看官有没有注意到右下角的neuron-core和neuron-link，对了解Nv gpu的同学是不是倍感熟悉呢？如果没有猜错的话，这里对标的就是nv gpu的cuda-core和nv-link。接下来我们看一下用户使用Trn1在cost上的一些收益。

图8 Trn1 收益

上面这张图展示的是Trn1跟p4d的对比，这里需要说明的是p4d是aws基于NVIDIA A100推出的HPC&ML实例。从收益上也可以看到使用Trn1在训练成本上能够减少50%，面对这样的成本收益客户很难不动心，尤其是在nv gpu价格不断上涨的情况下。看到这个数字不知道老黄做何感想，当然在羽翼未丰满之前aws还不敢直接甩开nv gpu单干，毕竟nv生态护城河依然很牢固。跟p4d能够组成大规模HPC&ML集群一样，aws也推出了基于Trn1的超算集群ultracluster。

图9 UltraCluster base on Trn1

ENA Express

ENA(Elastic Network Adapter) 和EFA(Elastic Fabric Adapter)前者是AWS EC2上标准的网卡，后者是HPC场景下使用的高性能网络设备(支持标准的libfabric API)。EFA高性能的背后就是AWS自研的网络协议SRD，它的核心目标就是降低网络传输上的尾部时延同时利用ECMP机制支持multi path load balance，而且SRD在发送端是支持out-of-order packet的，然后在接收端重新给包排序。SRD是基于aws nitro卡来实现的，所以它的实现得益于软硬协同。

在介绍ENA Express之前，我们先讲一下aws基于SRD在EBS上做的优化。简单的讲也就是将SRD引入到了EBS网络当中，虽然只是简单的引入但是背后的工作肯定不少。关于这一点可以看一下笔者最近的文章阿里云EBS存储网络加速方案演进，目前从topic上透露的数据来看，EBS的尾部时延降低了90%。

接下来我们聊一下ENA Express，那么从底层来讲就是将通用的tcp/udp offload到了SRD协议上。原来AWS的数据中心是有两大类流的：一类是基于SRD协议的，这主要用于HPC&ML这些对网络时延比较敏感的应用；另一外类就是基于普通tcp/udp的流。

图10 ENA Express

那offloadtcp/udp 具体是怎么做的呢？根据topic里面expose出来的信息，这里以TCP来例当SRD检测到到用户使用的是tcp时，SRD会跟对端自动建立一个SRD connection然后在协议层TCP包会被封装在SRD协议里面，当包被送到对端时会SRD硬件会执行一次解包的操作。由于利用了SRD的多路径和低尾部时延的特点，基于ENAExpress的普通TCP/UDP应用在带宽和延时上都得到了较大的提升，具体数据如下图所示：

图11 ENA Express Benefits

TWP base on Nitro SSD

Nitro SSD是aws在去年的reinvent上发布的产品，一款真正全自研的SSD。对ssd硬件比较了解的同学应该比较清楚，目前SSD存储介质上大家使用的都是NAND，而影响各家厂商SSD存储性能和抖动的主要因素就在FTL实现上。由于各家的FTL实现都不一样，近而就导致了在存储性能无法拿到一个统一的保障。

图12 different FTL of different vendors

为此aws自己实现了FTL并将其运行在nitro card上，同时bypass 硬件厂商直接跟NAND制造厂对接。这不仅实现了SLA的可控而且在成本了也大大降低。

之所以讲了这么多关于nitro SSD的内容主要是因为TWP的实现还是得益于aws 自研的可控的ssd。TWP全称为Torn Write Prevention 它主要用在io 密集型的应用比如mysql 或者MariaDB的场景来提升性能和降低时延。TWP产生的背景是这样的，通常数据库的场景写入page size一般是16KB，其数据校验也是针对这16KB来计算的，而目前的文件系统当中常用的大小都是以4K来计算的，因此数据库将一个16KB的数据写到磁盘上那在os级别上需要写4个块。在极端情况下（比如断电）往往并不能保证这一操作的原子性，比如写16K的数据，可能在写入4K 时发生了系统断电或者os crash ，只有一部分写是成功的，这样就产生了数据一致性问题了。为了解决这个问题，数据库实现上都会采用double write buffer的机制。具体来说就是当mysql将脏数据flush到data file的时候, 先使用memcopy 将脏数据复制到内存中的double write buffer，然后再通过double write buffer再分2次写入到共享表空间，最后再调用fsync函数同步到磁盘上。

图13 mysql double write buffer

而在TWP使能的情况下则无需double write buffer，你只需要将文件系统page大小修改为16kB即可，但是这些功能只会在使用nitro ssd的实例使用。它主要得益于nitro ssd对16KB page原子写入的支持。

图14 Torn Write Prevention

通过对比上面两张图我们可以清楚的看到TWP情况下，数据库写入也更高效。具体性能收益如下：

图15 TWP场景下性能数据

总结

上面就是从笔者的视角整理的一些技术创新点，当然想必每位读都有自己的一些看法也都有自己认可的一份创新技术清单。那单从笔者整理的这份技术清单来看，这次大会呈现的一些技术创新更多的是基于原来技术上的横向扩展。当然，这些创新依旧很有意思，依旧让人眼前一亮。坦诚地讲，不管是在软件上还是自研硬件上，今天aws依旧是云计算领域的技术领先者，国内云厂商要想追上其步伐还有很多的路要走。

从 Alder Lake 架构峰值测试看 CPU 并行编程新挑战

Alder Lake 大小核架构与拓扑在 Ubuntu 22.10 下运行 lstopo（可以通过 apt install hwloc 的方式获得），可以看到如下处理器拓扑结构：

△ 酷睿 i7 1280p 处理器结构拓扑

可以看到：

处理器 6 个大核心，以及 8 个小核心都识别到了。编号上，大核心在前，小核心在后，这个特性和 arm 在 Android 下是相反的。
每个大核心有独立的 L2，共享 L3，且有两个超线程。同一个核心的超线程优先编号，与早期 Linux 相反。
每个小核心只有一个线程。每四个小核心共享 L2 cache。

这样的架构拓扑，与以前的 CPU 拓扑有了很大差别。以前的架构，全部是同构核心，即便有 NUMA 这样非对称内存访问结构，也还算简单，并行程序在分配，管理，访问内存的时候注意区分本地内存和远端内存即可，在任务调度上不需要考虑因同样的任务在不同核心上计算效能的差异导致的负载不均衡问题。

所以旧版本的 cpufp 做多线程并行的方式，问题就很大了：假设所有核心都是同构核心，静态任务分配，会造成多核心测试负载不均衡；大小核超线程的数量的不同，以及超线程的新的编号方式，导致线程池的亲和性设置很难自动且正确地完成。基于这些问题，我修改了 cpufp 的绑核方式，需要在命令行参数由用户明确指定绑定线程的编号（图中的 PU 编号）。比如要开 6 个线程的线程池，绑定 6 个大核，那么需要运行：

./cpufp --thread_pool=[0,2,4,6,8,10]

要绑定小核，则参数可以用 “-” 号表示连续区间：

./cpufp --thread_pool=[12-19]

这样并没有解决自动负载均衡的问题，但是对于 cpufp 这个 demo 程序也足够用了。

新指令集 AVX VNNI

Alder Lake 架构虽然屏蔽掉了 AVX512 系列指令集，但是仍然保留了 AVX VNNI 指令集，可以把它看成是 AVX512 VNNI 指令集的 256 和 128 位子集。

但是，它是一个全新的指令集，在编码上与AVX512并不相同，指令需要加上{vex}前缀，否则生成的机器码是AVX512 VNNI的，在不支持AVX512 VNNI的CPU上会报illegal instruction，{vex}前缀表示编译成AVX版本的指令。

下面一段代码是测试 AVX VNNI 的 int8 峰值的代码：

cpufp_kernel_x86_avx_vnni_int8:
    vpxor %ymm0, %ymm0, %ymm0
    vpxor %ymm1, %ymm1, %ymm1
    vpxor %ymm2, %ymm2, %ymm2
    vpxor %ymm3, %ymm3, %ymm3
    vpxor %ymm4, %ymm4, %ymm4
    vpxor %ymm5, %ymm5, %ymm5
    vpxor %ymm6, %ymm6, %ymm6
    vpxor %ymm7, %ymm7, %ymm7
    vpxor %ymm8, %ymm8, %ymm8
    vpxor %ymm9, %ymm9, %ymm9
.cpufp.x86.avx.vnni.int8.L1:
    {vex} vpdpbusd %ymm0, %ymm0, %ymm0
    {vex} vpdpbusd %ymm1, %ymm1, %ymm1
    {vex} vpdpbusd %ymm2, %ymm2, %ymm2
    {vex} vpdpbusd %ymm3, %ymm3, %ymm3
    {vex} vpdpbusd %ymm4, %ymm4, %ymm4
    {vex} vpdpbusd %ymm5, %ymm5, %ymm5
    {vex} vpdpbusd %ymm6, %ymm6, %ymm6
    {vex} vpdpbusd %ymm7, %ymm7, %ymm7
    {vex} vpdpbusd %ymm8, %ymm8, %ymm8
    {vex} vpdpbusd %ymm9, %ymm9, %ymm9
    sub $0x1, %rdi
    jne .cpufp.x86.avx.vnni.int8.L1
    ret

VNNI指令集支持int8和int16两种精度，现在都已加入cpufp的benchmark里。同时新版本的cpufp可以在编译期（执行build.sh时）识别本机支持的指令集，直接生成支持指令集的benchmark测试，避免了旧版系统编译不了新指令集的问题。

Alder Lake 峰值测试结果与分析
修改后的 cpufp 代码在我的 i7-1280P 上测试结果如下：

$ ./cpufp --thread_pool=[0]
Number Threads: 1
Thread Pool Binding: 0
--------------------------------------------------
| Instruction Set | Data Type | Peak Performance |
| AVX_VNNI        | INT8      | 590.31 GOPS      |
| AVX_VNNI        | INT16     | 295.06 GOPS      |
| FMA             | FP32      | 149.87 GFLOPS    |
| FMA             | FP64      | 74.931 GFLOPS    |
| AVX             | FP32      | 112.39 GFLOPS    |
| AVX             | FP64      | 56.203 GFLOPS    |
| SSE             | FP32      | 56.054 GFLOPS    |
| SSE             | FP64      | 28.001 GFLOPS    |
--------------------------------------------------
$ ./cpufp --thread_pool=[0,2,4,6,8,10]
Number Threads: 6
Thread Pool Binding: 0 2 4 6 8 10
--------------------------------------------------
| Instruction Set | Data Type | Peak Performance |
| AVX_VNNI        | INT8      | 2636.8 GOPS      |
| AVX_VNNI        | INT16     | 1319.1 GOPS      |
| FMA             | FP32      | 670.05 GFLOPS    |
| FMA             | FP64      | 335 GFLOPS       |
| AVX             | FP32      | 502.4 GFLOPS     |
| AVX             | FP64      | 251.2 GFLOPS     |
| SSE             | FP32      | 250.42 GFLOPS    |
| SSE             | FP64      | 125.16 GFLOPS    |
--------------------------------------------------
$ ./cpufp --thread_pool=[12]
Number Threads: 1
Thread Pool Binding: 12
--------------------------------------------------
| Instruction Set | Data Type | Peak Performance |
| AVX_VNNI        | INT8      | 114.89 GOPS      |
| AVX_VNNI        | INT16     | 57.445 GOPS      |
| FMA             | FP32      | 57.444 GFLOPS    |
| FMA             | FP64      | 28.723 GFLOPS    |
| AVX             | FP32      | 28.723 GFLOPS    |
| AVX             | FP64      | 14.362 GFLOPS    |
| SSE             | FP32      | 28.312 GFLOPS    |
| SSE             | FP64      | 14.361 GFLOPS    |
--------------------------------------------------
$ ./cpufp --thread_pool=[12-19]
Number Threads: 8
Thread Pool Binding: 12 13 14 15 16 17 18 19
--------------------------------------------------
| Instruction Set | Data Type | Peak Performance |
| AVX_VNNI        | INT8      | 867.99 GOPS      |
| AVX_VNNI        | INT16     | 434 GOPS         |
| FMA             | FP32      | 434 GFLOPS       |
| FMA             | FP64      | 217 GFLOPS       |
| AVX             | FP32      | 217.01 GFLOPS    |
| AVX             | FP64      | 108.5 GFLOPS     |
| SSE             | FP32      | 216.39 GFLOPS    |
| SSE             | FP64      | 108.5 GFLOPS     |
--------------------------------------------------

第一个表格是单个大核的执行结果，可以看到如下特性：

AVX VNNI 指令集的 int8 吞吐，是 FMA 指令集（CPU 最大浮点吞吐指令）中fp32 的 4 倍；int16 则是 fp32 的 2 倍，与其他支持 dp4a 类指令架构非常一致。
SSE指令是AVX指令对应精度类型的正好1/2吞吐，这个与以往在intel先前架构也吻合。
AVX 指令和 FMA 指令对比，对应精度类型的吞吐大约是 3/4 (112.39÷149.87≈74.99%)。这就与 Intel 前面几代架构有了较大的差别。我在另外一台 10 代 Comet Lake 架构 CPU（桌面 Skylake 架构的某改 ya 良 gao 版）上测试的结果如下：

$ ./cpufp --thread_pool=[0]
Number Threads: 1
Thread Pool Binding: 0
--------------------------------------------------
| Instruction Set | Data Type | Peak Performance |
| FMA             | FP32      | 125.93 GFLOPS    |
| FMA             | FP64      | 62.898 GFLOPS    |
| AVX             | FP32      | 62.948 GFLOPS    |
| AVX             | FP64      | 31.491 GFLOPS    |
| SSE             | FP32      | 31.28 GFLOPS     |
| SSE             | FP64      | 15.686 GFLOPS    |
--------------------------------------------------

可以看出该架构中AVX指令对应浮点类型的吞吐是FMA指令的一半。

这是由于，Alder Lake之前的架构，浮点向量乘加类指令集中在port0和port1这两个发射端口（port5作为AVX512唯一完整的发射端口，经常在桌面架构或者低端服务器产品屏蔽掉浮点乘加），这两个端口一般各有一条256位的FMA单元。同时，这两个端口也支持256位的MUL和ADD指令，或者，其中一个端口支持MUL，另一个端口支持ADD。这样我们在测试AVX指令时用到MUL和ADD，分别只有FMA指令一半的吞吐（乘和加各算一次计算，所以乘加相比乘或者加单独的指令就是两倍的浮点吞吐）。然后我们再看一下Alder Lake大核Golden Cove的架构：

△ Intel 12 代处理器大核 Golden Cove 架构图

我们发现 Port5 也多了一条 FastADD 单元（Fast 指的是延迟周期更短）。这样，Golden Cove 在 Port0 和 Port1 各有一条 256 位的 FMA；在 Port0 和 Port1 各有一条 MUL（与 FMA 单元共享）；同时，Port1 和 Port5 各有一条 FastADD。因此 Port1 既可以发射 MUL，也可以发射 FastADD。

我们的 AVX 指令测试程序是下面这样乘加交换排指令流水的：

.cpufp.x86.avx.fp32.L1:
    vmulps %ymm12, %ymm12, %ymm0
    vaddps %ymm12, %ymm12, %ymm1
    vmulps %ymm12, %ymm12, %ymm2
    vaddps %ymm12, %ymm12, %ymm3
    vmulps %ymm12, %ymm12, %ymm4
    vaddps %ymm12, %ymm12, %ymm5
    vmulps %ymm12, %ymm12, %ymm6
    vaddps %ymm12, %ymm12, %ymm7
    vmulps %ymm12, %ymm12, %ymm8
    vaddps %ymm12, %ymm12, %ymm9
    vmulps %ymm12, %ymm12, %ymm10
    vaddps %ymm12, %ymm12, %ymm11
    sub $0x1, %rdi
    jne .cpufp.x86.avx.fp32.L1

执行的时候，第一个周期发射乘加乘，第二个周期发射加乘加，第三个周期又是发射乘加乘... 以此类推。三个端口支持乘和加1:2和2:1两种比例，都可以填满流水线。这样浮点吞吐量正好是两条FMA流水线的3/4，算是近几代 Intel 架构里一个不小的改进，为AVX和SSE（SSE就是简单地复用AVX的一半计算单元）优化的重型浮点程序，可以在Golden Cove上获得相当的性能提升（IPC提升）。

第二个表格，是6个大核的测试，由于低功耗版处理器的限制，多核频率达不到单核的6倍，所以整体计算吞吐没有达到6倍，表现算是正常。

第三个表格是小核心单核，可以看出如下几个特性：

AVX VNNI的int8吞吐只有FMA的fp32吞吐的2倍，int16与FP32的吞吐持平，小核的AI能力缩水不少。
小核心的浮点吞吐只有大核心的1/3多一点，一方面因为小核心只有一条FMA流水线，另一方面是频率也有差距。即便使小核心对比10代Comet Lake处理器，也只有不到1/2的吞吐（频率差距小一些）。
小核的AVX指令吞吐只有FMA的一半，与之前的架构一致，比起大核的差距拉的更大了（接近 1/4）。

再加上 Cache 容量和架构上的精简，小核实现同样计算的效率肯定是不如大核的。所谓小核接近 skylake 的说法，至少在浮点或向量密集型生产力应用上，小核就是鸡肋，帮不上什么忙。

第四个表格小核多核吞吐与大核类似，同样也达不到 8 倍。

CPU 并行编程新挑战

其实这个挑战从移动端 arm 架构引入 bigLittle 就开始了，但终究与桌面和服务器端有所不同。移动端SoC发展到今天，高通已经搞出单个SoC里，实现1+2+2+3四种异构核心。一个大核的能力非常强，中间两种中核比较接近，比大核慢1/3到一半左右，小核性能极差，基本只是为了跑一些常规应用时降低功耗。这样的系统环境，再加上由于电池环境导致的小核优先调度策略，使并行编程难如登天。我们为手机和APP业务开发计算密集型应用，在使用多核编程时候问题非常多，要么降频，要么优先调度小核，且没法控制，甚至很多时候大小核需要不同的代码来达到最优性能，根本无法兼顾，所以很多时候只是用单个大核在跑应用，减少复杂性和混沌。还好随着GPU OpenCL/Vulkan环境，以及SoC里面的DSP和AI加速器日趋成熟，我们很多移动端的项目已经大量迁移到这些更高效能的处理器中。但是桌面和云端环境，我们终究是希望利用多个CPU核心以提升总的效率。尤其是云端还面临核数众多，NUMA非对称内存访问等问题。

并行计算在划分任务的时候，通常分为静态划分和动态划分，目标都是为了给不同计算核心分配均匀的负载，以追求线性加速。静态，是按照可并行的线程单元数量，平均划分任务，且在运行时不能改变任务划分方式。动态则是在运行时，根据各个线程的状态，动态分配任务，使多个线程动态调整自己的负载，大致达到均衡状态。

前者的好处是方便开发，单个线程执行效率最高，对大多数并行度很好的程序有非常好的并行效果。后者的好处是可以根据运行时的各种突发问题做出调整，防止因条件变化导致任务负载不均。下面这个图展示了这两种调度方式在同构核心和异构大小核环境下的执行模式：

△ 两种调度方式在同构多核和大小核异构情况下的调度结果

左边展示了同构大核使用静态调度的方式，一般可以取得不错的负载均衡。中间这个图换成2大2小的核心，对于小核心，同样的任务执行时间变长，导致静态调度后，负载不均衡。大小核对于不同任务的执行速度比例也可能不一样（比如大小核分别计算FFT，是2:1的吞吐；计算矩阵乘法可能就变成4:1。甚至同一种计算使用不同参数，这个比例也会改变），很难根据不同架构来分配不同大小的静态任务。

唯一的办法，就如最后一张图所示，缩小单个任务的规模，增加任务数量，并进行动态调度，这样不同的处理器核可以根据自己的“胃口”，吃进适合自己的任务量，基本达到平衡。

过去的CPU都是同构核心，对于已有的，可以并行的软件和代码，为了开发简便，相当一部分并行的工作都是静态任务划分，比如简单调用 OpenMP 的循环并行。这样很容易造成大小核同时加速这个程序的时候，并行效果并不好。

同时，这种大量小任务动态调度的方式，还有一些问题：

对于这种调度方式，任务体量越小，数量越多，越容易达到负载均衡，均衡误差也越小。但是很多并行任务的并行度是有限的，可以拆成更细粒度的小任务是有上限的，天然限制了这个方案；同时每个任务有相对固定的拆分成本和调度成本，任务越多，拆分和调度的开销占比就越大。

另外，对于优化好流水线的单个计算任务来讲，如果拆成更小的任务，那么就会多出很多进出流水线的开销，如下图所示：

△大任务拆成小任务时，总体执行的延迟增加

所以总的来说，静态任务改成大量小任务动态划分和调度的方式，效果有其极限，随着任务拆分越多，延迟变化呈U字形变化，先降低后升高。

结语今后的 CPU 并行编程，我们要面对的困难更多了。除了要考虑核心越来越多，NUMA非对称这些问题，还要关注Intel 和 ARM 这些 CPU 大小核的异构任务调度问题。操作系统对这些问题的解决能力十分有限，寄希望于新内核对调度系统的改进，其实是缘木求鱼，只要不添乱就好了。任何严肃的大规模系统软件和生产力系统，都必须自己解决资源的调度和优化。Intel 最开始引入大小核的目的，其实是想在单核和多核两种场景都可以取得跑分的突破。但是忽略了对于现有大量遗留软件的适配难度问题，以及开发新软件带来的成本和难度的挑战。硬件性能的提升，还是尽量不要给软件带来太多负担为好。

GitHub: https://github.com/openppl-public

官网：https://openppl.ai

沈向洋：三十年科研路上的七条“过来人”经验

我从卡内基·梅隆大学计算机学院PhD 毕业后（1996年），想像导师（编者注：拉吉·瑞迪教授，1994年图灵奖获得者）一样以后做教授，先助理教授、副教授，然后教授这样，一条大路向前走，一直希望做一个教授。但事实上回过头来看，我过去这二三十年的整个过程发展，更加像是一条弯弯曲曲的道路。

今天我想给大家分享七个自己的经验和教训，我大概两年前在 Linkedin 上写了一篇文章，也做了一个总结。

你做不了所有的事情

第一件事情，当你职业生涯刚刚起步的时候，一定要明白你不可能做所有的事情，你可能有很多很多的想法，但是不见得什么事情都可以做到。

就像我刚才讲的，我一直想做教授，但是我在最后一刻改变主意了，我一个朋友说服了我去参加他的 start-up。他是这样说服我的，我跟他在车里谈了四个小时，他叫 Eric。他说：Harry，我最后终于明白了，你想当教授。他说：那简单，你先参加 start-up，先去赚很多很多钱，我给你的母校卡内基 · 梅隆捐一个 Harry Shum Professorship，指定你是第一个获奖人，这样的话你可以给学校再捐一个 Harry Shum Robotics Center。

当然这件事情没有发生。
事实上我后来参加了这样一个 start-up 以后，很快又加入了微软。当时很重要的一件事情，就是第一个孩子出生了。当时我想了一下两件事情不可以同时成立的：做 start-up 和带一个小孩子。但是孩子生出来了以后，你就没有办法去 Get rid of（摆脱），所以你只能 Get rid of start-up。这是第一个 lesson。致远

第二个 lesson，其实人一生的职业旅程非常长，首先我们职业生涯刚刚起步的时候，非常重要的一件事情就是在自己的专业一定要做得很深，你一定要有一件事情、某一个方向，大家知道你做了点什么样的工作。

我自己非常幸运参加微软，博士以后在微软研究院的时候，跟很多的同事，当时计算机视觉领域中非常优秀的工程师和科学家一起工作，包括待会儿上台的张正友博士，一起做了很多方面的工作。
我自己做的一个方向叫做 Motion Estimation，特别当时做全景图，就是 Panoramic Image，拍了几张照片以后把它拼起来这样。我也很自豪地跟大家讲，今天大家用手机拍全景图的时候，说不定也用了我们的技术。这件事情很重要，特别是你刚刚起步的时候。很多人忘记了，如果你不在某一个方向做到足够深的话，大家就记不住你。

第三点我想重点讲一下，就算是对工程师和科学家来讲，除了你专业做得好以外，最重要的一件事情大家不要忘记，就是一定要把故事讲好，story telling is the most important。
我一辈子听过很多了不起的演讲。很多很多年以前，在 SIGGRAPH 会议上我听过一个 keynote，是迪士尼的 VP of Imagination Engineering 做的演讲。为什么讲故事很重要？他说你在迪士尼看了那么多的电影、那么多的动画，不同的历史阶段，从二维动画到三维动画，到现在 VR 这些东西。这些实际上都不是最重要的事情，最重要的是大家喜欢迪士尼是因为迪士尼背后的这些故事。

对我们很多科学家、工程师来讲，我们也经常要做一些报告。大家做报告时，可能里面写的字非常非常多。我自己很幸运在很年轻的时候，研究生阶段就有机会参加了 SIGGRAPH，1995 年。这是我好朋友 Eric Chan 的报告，这是我一辈子见过的技术 Presentation 里面得到掌声次数最多的。他当时在苹果公司，写了一篇文章叫 QuickTime VR，当时我在苹果公司做实习生。Eric 在台上，他有特别的 Style，整个十几分钟的演讲，一共有八次掌声，我记得我在台下看着 Eric 演讲的时候，觉得非常了不起。一个中国人讲一口台湾腔英语，能够让大家有八次掌声，这非常非常了不起。

所以我就想在这里跟大家讲 story telling 非常重要，比如做 presentation，一张 slide 上面不应该超过七行字，多了以后大家看不清楚也搞不懂，这些东西都非常非常重要。

第四个 lesson，我想给大家讲的是一定要有目标，You get what you measure，一定要清楚自己最后要追求什么。

我自己非常荣幸，2004 年开始担任微软亚洲研究院院长，当时我们定下来的目标，就是说一定要成为世界上最了不起的研究院，后来我们也基本上达到这样一个目标。我记得 MIT Technology Review 曾经写过一篇封面报道叫《The World’s Hottest Computer Lab》。

那篇文章出来时，我正好在美国出差。美国机场这些地方有专门卖杂志的，我当时不知道 MIT Technology Review 的文章会出来，封面上就是我两个同事的照片。然后我就看看那个卖杂志的女士，我就跟她讲“May I have all your copies? ”那个女士很高兴，先收了我的钱，然后问我“May I ask why? ”然后我就很自豪地跟她讲，我说“Look, those two people on the cover, they work for me.”

所以你一定要有一个远大的目标，做了不起的事情。You get what you measure.

把握可控的，留心可见的，余下顺其自然

第五个 lesson，其实是我这么多年工作，特别是后来从研究部门到了产品部门以后，对处理所有问题的复杂性有了更深刻的认识以后，自己创造出来的一段话，叫做“Control the controllable, observe the observable, leave the rest alone”（把握可控的，留心可见的，余下顺其自然）。

我本科的时候念的是自动控制专业，大家有一些控制理论背景的话，就会对这个句式很熟悉。因为当时我从研究院调出去以后，到微软的产品部门做搜索引擎，做 Bing。我们的工作当然就是跟谷歌竞争，跟谷歌竞争当然不是开玩笑的事情，大多数人都会觉得跟谷歌弄的话下场肯定是很悲惨的。但是我很自豪地跟大家讲，现在微软 Bing 这样一个业务线的话，一年也挣 100 亿美元，所以我们其实做得还是相当不错的，在美国超过三分之一的搜索量来自于 Bing。
当时大家就在想：一个研究院来的人，他怎么可以去带产品线？所以我当时就在想，作为一个新兵到产品部门去工作，大家都问：你到这里来也没有做过产品，你可以给我们带来什么？我说我也不知道可以给大家带来什么，但是我想我至少可以跟大家保证，等我哪天离开这里的时候，大家会 remember me as the VP who knows how to party。
所以你一定要想到，你自己有哪些地方可以去 motivate 大家，可以把大家团结起来。哪些东西你自己是可以 control 的，如果你不可以 control 的话，你召集了也没有用，你就应该去观察这样的一些事情。所以在这件事情上大家一定要想。

这是我最喜欢的一张 slide，大家看过《教父》的话都会知道，Michael Corleone 经常讲，不管什么时候你遇到多大的困难，Difficult, not Impossible。Remember tha是一系列的项目

第六个 lesson，我想跟大家分享的，实际上我自己非常有幸，当时和前同事 Jim Gray，这个你们可能还记得，1998 年图灵奖得主，以前是微软研究院的研究员，他非常非常了不起，很不幸后来他独自驾船出海失踪了。
我对 Jim 非常敬仰，因为我当时正在从研究院去产品部门工作，我就请教他。我说：“Jim，你这一生的职业生涯非常了不起，得了图灵奖，又在研究院工作过，又在产品部门工作过，好像你从来就不介意你到底是在研究院工作，还是在产品部门工作。”
他就给了我一个非常好的 lesson，我还记得当时我们是在台北的一个酒店顶楼上交流。他说：“我从来不担心这个问题，到底是在研究院，还是在产品部门。Career is a series of projects，choose your project wisely. 你要选择你哪一个项目，你一生到最后的话，实际上就是你做过哪几个 projects。”

其实我的好朋友高文院士也讲过，他说你的职业生涯到了一定地步以后，大家就看你背上到底写了哪几个字，就是你做过哪几个 projects。特别是我们 50 位得奖的青年才俊，事业起步开始的时候，未来还有很光辉的道路。一定要记住，一个一个项目加起来。

最后，我想跟大家分享一个，我自己觉得特别是在美国的时候，跟美国的同事讲中庸之道。我有时候讲不过老美的时候，我就跟他们讲「子曾经曰过」，然后我把我想讲的东西跟他们讲一遍。
中庸之道，Always walk in the middle of the road。当然以前的路跟现在不一样，现在都分成左右两道。但是中庸之道里面还有一件非常重要的事情，并不是你只是 walk in the middle of the road，这里更重要的一点是 keep the direction，一定要明白自己前进的方向。

作者简介

沈向洋，1966年10月出生于江苏南京，主要专注于计算机视觉、图形学、人机交互、统计学习、模式识别和机器人等方向的研究工作，是计算机视觉和图形学研究的世界级专家。现任清华大学高等研究院双聘教授、美国国家工程院外籍院士、英国皇家工程院外籍院士、微软公司前执行副总裁、第三任微软亚洲研究院院长兼首席科学家、微软小冰公司的董事长。

电车人重磅发布：2022年度中国智能电动汽车核心零部件100强榜单

2022年度中国智能电动汽车核心零部件100强评选历时6个月，通过收集参评表、主动挖掘、专家与同行推荐、上下游调研和产业投资人访谈等多种方式跟踪研究产业链企业超过500家，历经初选、复选、终选三个阶段，最终有11大类、20余个小类、30多个细分领域，共计100家优秀产业链企业入选。

电车人将在2022年12月8日举办的第九届电车人大会上，分享100强统计报告及研究成果。

2022年度中国智能电动汽车核心零部件100强榜单如下，感谢行业各界朋友的关注和支持，让我们共同努力，为建设强大的中国智能电动汽车产业链贡献力量！

共11大类、20余个小类、30多个细分领域

总计100家企业入选

100强评选背景：

为搭建产业链优秀企业强强对话、共同提高的交流合作平台，电车人从2016年起推出中国电动汽车核心零部件100强研究项目，采用企业申报、专家与同行推荐、主动搜寻、投资人访谈、上下游调研、数据挖掘等多种方式梳理出全产业链30余个细分领域的优秀企业，推荐给全行业供合作参考，本研究项目以客观数据和实际经营情况为依据，真正做到专业、客观、公正。

核心零部件100强榜单一经推出，即在全行业引起强烈反响，成为产业发展的风向标，至今已持续发布了7年，逐步建立起具有中国特色、独立自主的产业链评价体系。真正实现全产业链核心资源的量化评价和动态跟踪，为产业内企业高效合作奠定基础。同期发布的100强报告也在逐年深化研究体系，统计分析产业链的核心经营数据，洞察行业最新竞争趋势，为企业中高层人士提供决策参考。 2022年度中国智能电动汽车核心零部件100强评选活动已经结束，100强榜单和100强研究报告将在2022（第九届）电车人大会上面向全行业隆重发布，感谢行业各界人士的积极参与和大力支持。

欢迎产业链优秀企业参与2023年度的100强评选！

参评规则说明：

1.重点关注独立经营的中国本土企业；

2.一家企业多种业务，重点关注新能源与智能汽车业务；一家企业多类产品，重点关注最强产品类型；

3.确保每一家入选企业都有相对明确的事实依据；

4.主要评价指标及权重分布：业务规模(40%)、优质客户覆盖(20%)、增长趋势(10%)、团队实力(15%)、资本实力(15%)。