第三届中国 Rust 开发者大会 安全高效的二进制序列化 Daniel Wang @ NEAR Borsh • 运行、编码效率 • 确定性 • 跨平台兼容性 二进制序列化的问题 Binary Object Representation Serializer for Hashing • 字节级别确定性 • 执行速度快 Borsh • 轻量级 • 每一个对象与其二进制表示之间都存在一个双射映射 中， borsh 并没有使用 serde • 全部逻辑原生实现 • 序列化、反序列化速度大幅领先其他解决方案 执行速度 执行速度 benchmark 执行速度 benchmark 执行速度 benchmark 执行速度 benchmark • 编译后的体积更小 • borsh 序列化后的二进制更精简 轻量级 序列化结果体积对比 Borsh 基本用法 Case Study NEAR NEAR 智能合约 Case Study Solana 智能合约 Case Study • non self-describing • 保证序列化后的二进制唯一性和确定性 • 主要序列化规则 Borsh 规范 • 整数采用低字节序（ little endian) 存储 • 对于动态长度的集合，先用一个 u32 存储集合 size • 对于原本无序的集合（如 hashmap ），存储时使用

银行证券保险 企业、公安部、上海市公安局、武汉市公安局等 100+ 公安机构，国家电网、 国信通产业集团等电力能源行业提供数据智能产品解决方案及长期服务。 海致专注为政府、金融、能源等客户提供大数据处理、分析、挖掘服务，在互 联网技术基础上，打造专业、易用的企业级大数据实战应用产品及解决方案。 北京中关村总部 武汉运维中心 深圳研发中心 上海应用中心 专注于数据智能技术赋能中国数字经济发展 AtlasGraph 大规模图数据分析平 台”荣获中国计算机学会（ CCF ： China Computer Federation ）“ 2021 年 CCF 科 学技术奖科技进步卓越奖”。 伴随市场对于知识图谱应用的不断深入，图数据规模和应用性能之间的矛盾愈 加凸显，海致针对以上背景展开了系统性的技术攻关，解决了图数据的高效存 储、索引及复制难题，提出了基于图缩减的高效分析方法，并孵化出了一个大 规模图数据分析平台 AtlasGraph 。 5 获得 2022 年中国电子学会科学技术奖科技进步一等奖 中国电子学会发布的《 2022 中国电子学会科学技术奖公告》，海 致星图与北京邮电大学、蚂蚁科技集团有限公司、中移动信息技术 有限公司联合研发的“大规模复杂异质图数据智能分析技术与规模化 应用”项目，斩获“科学技术奖科技进步一等奖”，这也是国内电子信 息领域的最高奖项。 该奖

。流水线的目的是能把原本 串行的一系列指令并行化。为了理解为什 么需要流水线，我们先反过来，假设没有 流水线，会有什么坏处。 • 例如，右边你今天早上的任务清单。 • 请问你这些任务总共需要多少时间？ 任务 时间 占用资源 洗脸 5 分钟 眼睛，嘴巴，手 烧开水 10 分钟 煤气灶 刷牙 5 分钟 嘴巴，手 看比站 15 分钟 眼睛 吃饭 30 分钟 嘴巴，手 拉粑粑 20 分钟 屁股 干瞪眼，什么也不做，其实完全可以在烧 开水的同时洗脸刷牙呀！原始的 CPU 也 是这样， ALU 在运算的时候指令解码单元 就在旁边干瞪眼，要等 ALU 跑完写回寄 存器来指令解码单元才开始继续工作，很 低效。 任务 时间 占用资源 洗脸 5 分钟 眼睛，嘴巴，手 烧开水 10 分钟 煤气灶 刷牙 5 分钟 嘴巴，手 看比站 15 分钟 眼睛 吃饭 30 分钟 嘴巴，手 拉粑粑 20 分钟 屁股 洗脸 烧开水 更高效的办法是，观察每个任务都占用哪些 资源，所占用资源不冲突的可以同时进行， 节省时间。 • 例如洗脸需要眼睛嘴巴手，刷牙需要嘴巴手 ，那么洗脸和刷牙不能同时进行。但是烧开 水只需要占用煤气灶，和洗脸刷牙不冲突， 所以可以一边烧开水一边洗脸刷牙。 • 所以让小彭老师来优化的话，可以只需要 5 + 5 + 10 + 20 = 40 分钟，比你快一倍多。 任务 时间 占用资源 洗脸 5 分钟 眼睛，嘴巴，手 烧开水

低质量 / 低效率 / 高成 本： 人淹没在系统的海洋里，无数平台手工切换 高人效 / 高质量 / 高效率 / 低成 本： 人在系统之外 / 上，复杂性下沉到单一平台 希望 工程师不再花时间在开发写代码之外的脏活累活，比如服务部署、找环境，服务编排等 Infra 的事情。 1 0 0 % 开 源 基 本 能 力 开 源 1.5 个月核心重构 65% 功能实现开源 支撑开源社区开发者环境 行业方案 对比分析 职能 传统 DevOps 方案 ZadigX 云原生 DevOps 方案 降本提效 组织能力提升 业务负责人 研发不透明，规划凭感觉： • 发版时间靠运气 • 团队熬夜冲进度 研发透明化：不同项目清晰可见的效率、质量、进度 进度管理：根据团队客观数据，预测和确定项目规划 迭代进度一目了然 项目从无到有可核算 管理有数据科学依据 解放管理，更多时间花在 业务创新 人工低效操作减少 80% 构建资源利用率提升 60% 业务资源利用率提升 30% 统一治理内部规范，开发 自助上线；解放运维，工 作重心向业务稳定性保 障，建设平台工程体系 研发 研发时间被大量占用： • 本地开发环境难模拟 • 多业务联调艰难，诊断耗时多 • 出现问题诊断耗时多 • 流程割裂协作痛苦，响应慢 调试自测免打扰：本地 / 子环境免打扰，独立完成验证工作 自助验证更高效：自动化工作流

4 核且矢量化成功： 1 次浮点读写 ≈ 128 次浮点加 法 常见操作所花费的时间 • 图中加法 (add) 和乘法 (mul) 都指的整数。 • 区别是浮点的乘法和加法基本是一样速度。 • L1/2/3 read 和 Main RAM read 的时间指的是 读一个缓存行（ 64 字节）所花费的时间。 • 根据计算： 125/64*4≈8 • 即从主内存读取一次 float 花费 二级缓存有 256 KB ， 6 个物理核心每个都有一个， 总共 1.5 MB 。 • 三级缓存由各个物理核心共享，总共 12 MB 。 通过图形界面查看拓扑结构： lstopo 根据我们缓存的大小分析刚刚的图表 • 也可以看到刚刚两个出现转折的点，也是在 二级缓存和三级缓存的大小附近。 • 因此，数据小到装的进二级缓存，则最大带 宽就取决于二级缓存的带宽。稍微大一点则 只能装到三级缓存，就取决于三级缓存的带 不得不同时维护很多条预取赛道（ mc_x, mc_y, mc_z ），当赛 道多了以后每一条赛道的长度就变短了，从而能够周转的余地时间比较少，不利于延迟隐藏。 而如果把这三条赛道合并成一条（ mc ），这样同样的经费（缓存容量）能铺出的赛道（预 取）就更长，从而 CPU 有更长的周转时间来隐藏他内部计算的延迟。所以本案例中 AOS 比 SOA 好。 AOS 、 SOA 、 AOSOA 哪家强：结论 •

这样，在 cudaDeviceSynchronize() 以后 ，应该可以获取数据了吧？ • 结果令人失望，尽管给 kernel 传了指向 ret 的指针，但 ret 的值并没有被改写成 功。 分析返回的错误代码 • CUDA 的函数，如 cudaDeviceSynchronize() 。 • 他们出错时，并不会直接终止程序，也不会抛出 C++ 的异常，而是返回一个错误代码，告诉你出的具体什么 算的是否准确无误，从右边的输出 可以看到基本是一致的。 测试一下时间 • 使用第六节课中的 ticktock.h 测试一下 CPU 和 GPU 的用时。 • 注意，这里一定要把 TOCK 放到同步之 后。原因之前说过，因为对 GPU 核函数 的调用是异步的，只有 cudaDeviceSynchronize() 以后才真正完 成执行，才能算出真的时间。 • 查看结果，发现 GPU 比 CPU 快了很多 通常板块数量总是大于 SM 的数量，这时英伟达驱动就会在多个 SM 之间调度你提交的 各个板块。正如操作系统在多个 CPU 核心之间调度线程那样…… • 不过有一点不同， GPU 不会像 CPU 那样做时间片轮换——板块一旦被调度到了一个 SM 上，就会一直执行，直到他执行完退出，这样的好处是不存在保存和切换上下文（寄 存器，共享内存等）的开销，毕竟 GPU 的数据量比较大，禁不起这样切换来切换去……

使用门槛极低 现存做法大多以「单点工具 + 写脚本」或运管类平台为主， Zadig 则是面向开发者视角，中立，云原生一体化价值链平台。 与现存 DevOps 方案对比： 现存方案 典型代表 方案特点分析 Zadig 优势 传统 Jenkins 方案 GitLab + Jenkins + 脚本化 运行效率低，管理维护成本高 方案局限性大，安全性风险高 无法支持敏捷交付模式 支持从需求到发布全流程敏捷交付。尤其面向 发布 洞察 一堆复杂脚本、维护成本极高 员工手工操作费时费力易出错 手动更新服务、手动打包、交付 付效率低下、占据大量研发时间 、研发利用率极低 环境不透明、测试效率低下、测 试有效性低、大量手工、价值难 以体现 上下游烟囱式、协作效率低、团 队花大量时间在碎片化沟通和流 程制定上、各方能力受限、无法 快速响应市场需求 层级越高、对产研状态越模糊 管理低效、延误战机 少量配置、快速拉起环境、稳定 工作流更新环境进行集成验证 包括步骤：构建 -> 部署 sit 环境 -> 接口测试 -> IM 通知 Sprint 发布 需求开发 变更发布 产品规划 测试验证 自动化测试——测试结果分析 Sprint 发布 需求开发 变更发布 产品规划 测试验证 uat 发布——执行 uat 工作流做预发布验证 步骤包含：质量门禁 -> 构建 ->nacos 变更 -> 部署 uat

defl; • } • } • 封装成函数方便使用： • auto val = map_get(m, “key”, “default”); • ss map 常用函数不同情况下的行为分析 类型 C++ 代码 key 已存在 key 不存在 读取 val = m.at(key) 读取这个值 抛出 out_of_range 异常 val = m[key] 读取这个值 创建并零初始化（默认构造函数） erase(key) 删除这个值 默默放弃 小彭老师四定律： 读取，要用 at 。 写入，要用 [] 。 判断存在，用 count 。 删除，用 erase 。 这四个已经够用了。 map 常用函数不同情况下的行为分析 类型 C++ 代码 key 已存在 key 不存在 读取 val = m.at(key) 读取这个值 抛出 out_of_range 异常 val = m[key] 读取这个值 创建并零初始化（默认构造函数） 类型在栈上的空间就要消耗 32 字节，更不用说可能堆上还有），深拷贝一下要花费不少 时间。 • for (auto [k, v]: m) { • print(k, v); • } map 的遍历：不修改也建议加引用 k v （假如非常大的话） map 中的 堆空间 执行你这段代码 的栈空间 & ( 深拷贝，浪费时间 ) v （假如非常大的话） • 其实，就算遍历时不修改，还是建议加引用，在

不能中国人向国外输出作品 Rust 缺少学习资源 Rust 未来大有可为 Rust 在操作系统，数据库，各种框架和工具上应用范围 广 写作动机 当情况不明时，抱着一个纯粹的目标干事就行了，其他 的留给时间检验。不懂就学，技术写作更像一种共创， 要反复总结和修改 ( 费曼学习法 ) 。 写作本书给我的启示 基础、排序、查找、树、图 代码框、颜色、图片绘制均由 Latex 完成 可参考点 为什么 抽象数据类型 什么是抽象数据类型？ 为什么需要抽象数据类型？ 时空复杂度 • 时间复杂度更被看重 • 时间和空间复杂度不是对立的，可以协同 时间和空间复杂度 复杂度计算 • 大Ｏ标记法（数量级近似） • 用 AI 来估计 算步骤、算存储 Rust 基本数据结构复杂度 线性数据结构 非线性数据结构 总体来看，时间复杂度没有超过 O(n) 的！ Rust 实现数据结构 • 栈 • 链表 联想：图数据结构的的点、边、面似乎满足欧拉公式 : V – E + F = 2 、则时间复杂度为： O(V+E) = O(2E – F + 2) • V = 14; E = 18; F = 5 + 1; • V+E = 32 • 2E – F + 2 = 32 总结及学习资源 • 算法总结 • 学习资源 总结及学习资源 Rust 算法总结 • 复杂度分析及算法优化 • 别自己实现，用标准库 • 利用

• OOXML - Excel 解析库 • xlsx2csv - Excel 转 CSV 工具 • Unqlite - 单文件非关系型数据库 • Wisecondor - 生物信息 CNV 分析 • mdsn - A Multi-address DSN(Data Source Name) parser. TDengine 应用开发组 • Python/Rust/Go 连接器 • 数据可视化 com/taosdata/TDengine 全球 50 多个国家安装实例超 270k ｜ GitHub 全球趋势排行榜多次排名第一 TDengine - 数据模型 1. 设备 ID 及关联属性（ Tags ） 2. 时间戳 3. 结构化采集量 STable 超级表 Table 子表 CREATE STABLE `meters` ( `ts` TIMESTAMP, `current` FLOAT, 模块之间关联性不高但模块组成复杂，可维护性差 • 大量设备大量数据归集存储，存储压力大 • 数据总线 / 消息队列消息接入，定制化程度要求高 • 数据业务逻辑自定义需求强 • 一定的实时数据分析能力 taosX - 功能路线图 集群运维 数据接入 流式处理 流式处理 数据分享 开放平台 • Backup/Restore • Replication • Migration •