第三届中国 Rust 开发者大会 使用硬件加速 Tokio 演讲人： Loong.Dai, Cathy.Lu Loong Dai • Intel 云原生工程师 • 微软 MVP • Dapr 、 Thanos 、 Golangci-lint 的 Maintainer • 现在主要专注于服务网格领域，探索云原生软硬件结 合新范式 • Github ID: daixiang0 自我介绍

cpu-bound 与 memory-bound • 通常来说，并行只能加速计算的部分，不能加速内存读写的部分 。 • 因此，对 fill 这种没有任何计算量，纯粹只有访存的循环体，并 行没有加速效果。称为内存瓶颈（ memory-bound ）。 • 而 sine 这种内部需要泰勒展开来计算，每次迭代计算量很大的 循环体，并行才有较好的加速效果。称为计算瓶颈（ cpu- bound ）。 • 并 指的是分支预测是否成功。 多少计算量才算多？ • 看右边的 func ，够复杂了吧？也只是勉勉强强超过一 点内存的延迟了，但在 6 个物理核心上并行加速后， 还是变成 mem-bound 了。 • 加速比： 1.36 倍 • 应该达到 6 倍（物理核心数量）才算理想加速比。 加速曲线 • funcA 用了 2 核就饱和。 • funcB 用了 4 核才饱和。 • funcC 用了 6 核才饱和。 • 时，我们的缓存装不下了，不得不把之前存储 的 a[i] 写回主内存。 • 这种代码在主内存看来， CPU 做的事情相当于：读 + 写，从而 每个元素只需要访问两遍内存。对这种完全 mem-bound 的程 序而言就是加速了 2 倍。 测试结果 可见，能否很好的利用缓存，和程序访问内存的时间局域性有关。 案例：一维 jacobi 迭代 • 一些物理仿真中，常用到这种形式的迭代法： • for (i=0...n)

1 分钟后 4 个处理器都渲染完毕得到结果。 • 最后只需将 4 个小块拼接起来即可得到完整 的 cornell box 图像。总共只花了 1 分钟。 图形学爱好者：我看中的是多核，目的是加速比，如果是单核，那多线程对我无用！ 某互联网公司：我看中的是异步，目的是无阻塞，即使是单核，多线程对我也有用。 因特尔开源的并行编程库： TBB https://link.springer.com/chapter/10 任务，一个负责下载，一个负责和用户交 互。并在主线程中等待该任务组里的任务 全部执行完毕。 • 区别在于，一个任务不一定对应一个线程 ，如果任务数量超过 CPU 最大的线程数， 会由 TBB 在用户层负责调度任务运行在 多个预先分配好的线程，而不是由操作系 统负责调度线程运行在多个物理核心。 封装好了： parallel_invoke 更好的例子 第 1 章：并行循环 时间复杂度（ time-efficiency 至有牺牲工作复杂度换取时间 复杂度的情形。 • 并行算法的复杂度取决于数据量 n ，还取决于线程数量 c ，比如 O(n/c) 。不过要注意如果线程 数量超过了 CPU 核心数量，通常就无法再加速了，这就是为什么要买更多核的电脑。 • 也有一种说法，认为要用 c 趋向于无穷时的时间复杂度来衡量，比如 O(n/c) 应该变成 O(1) 。 映射（ map ） 1 个线程，独自处理 8 个元素的映射，花了

新一代图技术应用特征简介 Takeaway AtlasGraph 架构概览 存储层 副本管理 CRAQ 图原生存储 索引 LSM-Tree 容灾保障 （ BR ） 元数据层 事务管理 MVOCC 计算层 Cypher AST 优化器 图计算 内存加速引 擎 服务接口 HTTP/RPC Spark 连接器 Python UDF UDF 执行器 索引管理 一致性存储 RAFT 分片管理 元数据 集群管理 用户权限 GNN 应用层 Atlas 图平台 Atlas Studio Atlas Client 基础 设施 Docker/K8S/VM X86/ARM - 基于 RUST 语言保证性能优势 - 分布式架构性能可线性扩展 - 针对大规模图优化的存算引擎 - 配合 Atlas 引擎，减少网络传输和内存压力 实际执行时，执行器等待流数据，处 理后将数据推送到下一个执行器 切分执行计划，将执行计划划分成不 同的执行阶段 内存缓存结构：加速图数据查询 • 由于图数据的查询通常是 IO 密集型，且访问的数据随机又分散，拥有内存缓存能起到很 好的加速效果 • 要想让内存缓存发挥最大的作用，就要能在有限的内存中存下尽量多的图数据 • 例如，对于属性的存储，可以通过自行序列化 / 反序列化大幅节省内存

float 的代码，从而增强你程序的吞吐能力！ • 通常认为利用同时处理 4 个 float 的 SIMD 指令可以加速 4 倍。但是如果你的算法不 适合 SIMD ，则可能加速达不到 4 倍；也有因为 SIMD 让访问内存更有规律，节约了指 令解码和指令缓存的压力等原因，出现加速超过 4 倍的情况。 第 1 章：化简 编译器优化：代数化简 编译器优化：常量折叠 编译器优化：举个例子 编译器优化：我毕竟不是万能的 memcpy/memset 的调用，影响 可读性。编译器会自动分析你是在做拷贝 或是清零，并优化成对标准库这俩的调用 。 从 0 到 1024 填充： SIMD 加速 paddd ：四个 int 的加法 movdqa ：加载四个 int 从 0 到 1024 填充： SIMD 加速（续） 看不懂？小彭老师解析一下。右边是方便大家理解的伪代码： 一次写入 4 个 int ，一次计算 4 个 int 的加法，从而更加高 大小的数组存储为 AOS 。 优点： SOA 便于 SIMD 优化； AOS 便于存储在传统容器； AOSOA 两者得兼！是王鑫磊的最 爱。 缺点：需要两层 for 循环，不利于随机访 问；需要数组大小是 4 的整数倍，不过 可以用边界特判法解决。 测试一下加速了多少倍？ 优化前： 优化后： 测试结果 SOA + unroll 的方案，比优化前快了 5 倍 ！ 并行情况下最快的也是 SOA 。

parallel for collapse(2) 遍历二维区间。 把 func 捕获为 firstprivate ，从而支持用 lambda 捕获的访问者模式。 实现访问者模式 • 额，总之就是每一层都有一个缓存。 第 5 章：量化整型 使用 int ：每个占据 4 字节 • 记得我第七课说过，一个简单的循环体往 往会导致内存成为瓶颈（ memory- bound ）。 • 右边就是一个很好的例子。 • 这是因为 i % 2 的计算时间，完全隐藏在内存 的超高延迟里了。 • 可见，当数据量足够大，计算量却不多时，读写 数据量的大小唯一决定着你的性能。 • 特别是并行以后，计算量可以被并行加速，而访 存却不行。 使用 int8_t ：每个占据 1 字节 • 因此我们可以把数据类型变小，这样所需的内存 量就变小，从而内存带宽也可以减小！ • 对于右边这种内存瓶颈的循环体，从 4 字节的 100 （看图可知：浮点数在 0 附近精度高） 定点数的好处：用 int16_t 表示 • 转成定点数的一大好处就是可以用任意大小的整数来 存储。这样就节省了一半带宽，从而加速了 2 倍。 能不能再小一点：用 int8_t 表示 • 发现结果不对了……说明 int8_t 太小了（可以容纳 - 128 到 127 ），容纳不下 97*100 这么大的数，发生 了溢出导致结果错误。

进一步求值： if (“world” MATCHES “Hello”) 从而会执行假分支，结果不正常了。 解决：用引号包裹起来，防止被当做变量名 初学者如果搞不明白，可以把所有不确定的地方都套上一层引号， 例如” ${MYVAR}” ，这样就可以避免被 if 当做变量名来求值了。 第 10 章：变量与作用域 变量的传播规则：父会传给子 • 父模块里定义的变量，会传递给子模块。 变量的传播规则：子不传给父 • 如果父模块里本来就定义了同名变量，则离开子模块后仍保持父模块原来设置的值。 如果子模块需要向父模块里传变量怎么办？ • 可以用 set 的 PARENT_SCOPE 选项，把一个变量传递到上一层作用域（也就是父模 块）。 如果子模块需要向父模块里传变量怎么办？ • 如果父模块里没有定义 MYVAR 的话，也可以用缓存变量向外部传变量（不推荐）。但是 这样就不光父模块可见了，父模块的父模块，到处都可见。 (DEFINED CACHE{x}) 判断是否 存在这个缓存变量，但是 set(CACHE{x} ...) 就不 行。 从 bash 设置环境变量试试看 第 11 章：其他小建议 CCache ：编译加速缓存 • 用法：把 gcc -c main.cpp -o main 换成 ccache gcc -c main.cpp -o main 即可 • 在 CMake 中可以这样来启用 ccache （就是给每个编译和链接命令前面加上

因此可以通过网格跨步循环增加每个线程访问 arr 的次数，从而超过共享内存部分的时间。 • 当然也别忘了在 main 中增加 gridDim 的大小。 通过模板函数包装一下 使用板块局部数组（共享内存）来加速数组求和 这就是胡渊鸣所说的 BLS （ block-local storage ） 进一步，当数组非常大，缩减后的数组可以继续递归地用 GPU 求和 • 这是第六课说过的方法。递归地缩并，时间复杂度是 为什么需要多维？直接手动求模运算获取 x ， y 坐标不行吗？看右边这个例子。 • 回顾一下：我们第七课讲过， CPU 上的 并行 for ，通常会做循环分块提升缓存局 域性。但是如果我们是传统的两层的 for 循环就低效了，对于矩阵转置这种需要 y 方向非连续访问而言，循环分块会带来很 大提升。 • 所以该怎么做才能让 GPU 也循环分块呢 ？ 第七课（访存优化）的录播可以看这里：

没 法 做 ” 更多 Zadig 应用场景 Zadig 应用场景 加速云原生转型 / 容器化 / 多云迁移 微服务大规模的容器化转型，优 化 & 增强 DevOps 工具链的建 设 典型客户：路特斯、七牛、非 码、连尚、锅圈、埋堆堆、九州 通 研发效能提升（开发、测试、发布工程） 优化加速产研流程，工程师团队级规模化协 作，消除工具孤岛，系统性的提升人效 典型客户：字节飞书、云器、驭势、小鹏、

● 事务层与账户层分 离 ● 独立水平扩展 ● CQRS ● Event Sourcing ● 针对读场景，写场 景分别优化 ● 稳定的底层 API ● 灵活的顶层 API ● 树状结构 ● 聚合查询 ● 正确性：内存安全，线程安全 ● 可靠性： Raft 共识算法 raft-rs ● 高性能：关键路径无锁单线程 顶层架构 ● Gateway 路由层 ○ 业务 Marker 事务层 ○ 使用业务 id 进行路由 ○ 执行转账计划 ○ 分发账户变动请求 ● Auticuro 账户层 ○ 使用账户 id 进行分区 ○ 执行账户变动请求 ○ 更新账户余额 分布式账务系统 性能展示 8 vCPUs * 5 节点 SSD 磁盘 当 TPS = 10K 时， 延迟 P99 < 20ms 分布式账务系统 高吞吐，超低延迟 账户层： Auticuro Auticuro 分布式账务系统 账户层： Auticuro ● 1. 接受转账请求，转换成 events ○ Tokio + Tonic 分布式账务系统 1 2 3 4 ● 1. 接受转账请求，转换成 events ● 2. 将 events 送入 Raft 共识，等待 events 被多数节点保存 ○ 共识：基于 raft-rs 的可靠消息队 列 ○ 存储： Rocksdb