个缓存行，而不是一个。 • 这样一次随机访问之后会伴随着 64 次顺序访问， 能被 CPU 检测到，从而启动缓存行预取，避免了 等待数据抵达前空转浪费时间。 页对齐的重要性 • 为什么要 4KB ？原来现在操作系统管理内存是用分页 （ page ），程序的内存是一页一页贴在地址空间中的， 有些地方可能不可访问，或者还没有分配，则把这个页设 为不可用状态，访问他就会出错，进入内核模式。 • 因此硬件出 int[n]{} ：后面加个花括号，就和 vector 一样，两次一样快了 结论 • 原理，当调用 malloc 时，操作系统并不会实际分配那一块内存，而是将这一段内存标记 为“不可用”。当用户试图访问（写入）这一片内存时，硬件就会触发所谓的缺页中断 （ page fault ），进入操作系统内核，内核会查找当前进程的 malloc 历史记录。如果发 现用户写入的地址是他曾经 malloc 过的地址区间，则执行实际的内存分配，并标记该段 sizeof(int)) 、 new int[n] 不会初始化数组为 0 。 • 初始化数组时，内存被写入，所以操作系统这时候才开始实际分配内存。 • 刚才的案例里，不会初始化的 malloc ，第一次往里面赋值时，因为这时操作系统还没有给 这个数组分配内存，所以会触发缺页中断，进入操作系统内核给数组分配内存，是内核执 行内存分配的这个动作，花费了额外的时间。而第二次因为内存已经被分配上了，所以再

服务多活，保证图库不会出现单点 故障。 Raft 服务高可用方案 偏向分析型的分布式事务 【 MVOCC 事务提交】 基于多版本乐观并发控制技术的分布式事 务实现，在保障一致性的前提下，提供优 秀的分析性能 分布式事务技术方案 MVOCC 处理流程 全面的算法支持  覆盖全部常用算法 • 路径计算、社区检测、相似度计算 等  丰富的自研图算法 • 环路识别、链路识别、节点间全路径、 业务效果提升 10%+ 灵活易用的开发平台 • AtlasML Python Library • 集成 Jupyter Notebook 超参数自动优化 • 支持超参数自动调优，解放算 法科学家生产力，避免繁杂的 手动调参 海致图神经网络平台特点 Rust 语言特性助力构建高性能图数据库 01 利用 Rust Stream 进行数据流式 处理 02 03 协程和严格的内存安全性，编译 团队成员来自清华、北大、人大、北邮等高校，对图技 术、存储技术充满热爱 Young 、 Passion 、 Techie About team 6 年 Rust 开发经验、用 Rust 写过操作系统 （ Occlum ）、编译器（ Rustc ），现在在用 Rust 写数 据库系统（ AtlasGraph ） About me About US shenyouren@stargraph

用于定义核函数，他在 GPU 上执行，从 CPU 端通过三重尖括号语法调 用，可以有参数，不可以有返回值。 • 而 __device__ 则用于定义设备函数，他在 GPU 上执行，但是从 GPU 上调用的，而 且不需要三重尖括号，和普通函数用起来一 样，可以有参数，有返回值。 • 即： host 可以调用 global ； global 可以调 用 device ； device 可以调用 device 上的函数。 同时定义在 CPU 和 GPU 上 • 通过 __host__ __device__ 这样的双重修 饰符，可以把函数同时定义在 CPU 和 GPU 上，这样 CPU 和 GPU 都可以调 用。 让 constexpr 函数自动变成 CPU 和 GPU 都可以调用 • 这样相当于把 constexpr 函数自动变成修饰 __host__ __device__ ，从而两边都可以调用。 比如这里设置了 RTX3000 系列的架构版 本号 86 ，在 RTX2080 上就运行不出结 果。 • 最坑的是他不会报错！也不输出任何东西 ！就像没有那个 kernel 一样！所以一定 要注意调对你的版本号。否则就会这样 kernel 好像没有执行过一样，只有 CPU 上的代码被执行了。 指定多个版本号 • 可以指定多个版本号，之间用分号分割。 • 运行时可以自动选择最适合当前显卡的版

PPT 和代码： https://github.com/parallel101/course 本课涵盖：稀疏矩阵、 unordered_map 、空间稀 疏网格、位运算、浮点的二进制格式、内存带宽优 化 面向人群：图形学、 CFD 仿真、深度学习编程人 员 第 0 章：稀疏矩阵 稠密数组存储矩阵 用 foreach 包装一下枚举的过程 改用 map 来存储 分离 read/write/create ）不一定就是完美解决方案，要根据实际情况判断。 真正的解决： tbb::spin_mutex 其实主要的瓶颈在于 std::mutex 会切换到操作系统内核中去调度 ，非常低效。而 tbb::spin_mutex 则是基于硬件原子指令的，完全 用户态的实现。区别： std::mutex 的陷入等待会让操作系统挂起 该线程，以切换到另一个；而 tbb::spin_mutex 的陷入等待是通过 不断地 while (locked); 发现结果不对了……说明 int8_t 太小了（可以容纳 - 128 到 127 ），容纳不下 97*100 这么大的数，发生 了溢出导致结果错误。 试图解决：用 uint8_t 表示，定点数系数调小到 2 • 注意到我们的值始终是正数，因此可以用无符号的 uint8_t （可以容纳 0 到 255 ），然后把刚刚的系数 100 改小到 2 ，成功算对结果了，代价是精度损失了 不少。

角色： 产品 / 架构 开发 测试 运维 运维 / 开发 技术支持 事件 需求设计 架构设计 拆任务、写代码 代码集成 xN 单元测试验证 xN 代码扫描 xN 自测、联调 xN 集成验证 xN 写测试用例 系统验证 xN 自动化测试 xN 性能测试 xN 安全测试 xN 数据变更 xN 代码变更 xN 配置变更 xN 2022 年 9 月 场 景 深 化 能 力 增 强 Helm/K8s YAML/ 托管场景接入流程优化 UX/UI 升级，工程师一线体验优化 推出效能看板，实时客观度量工程数据指标 效 率 优 化 、 开 发 者 体 验 增 强 2023 年 面向生态伙伴开放场景 面向开发者提供 IDE 插件 / 自测环境 通用工作流广泛链接生态赋能开发者 企业解决方案和最佳实践内置 发布 业务资源利用率提升 30% 统一治理内部规范，开发 自助上线；解放运维，工 作重心向业务稳定性保 障，建设平台工程体系 研发 研发时间被大量占用： • 本地开发环境难模拟 • 多业务联调艰难，诊断耗时多 • 出现问题诊断耗时多 • 流程割裂协作痛苦，响应慢 调试自测免打扰：本地 / 子环境免打扰，独立完成验证工作 自助验证更高效：自动化工作流 + 云上环境，高效验证调试 安全发布有信心：

据变更、部署生产环境（变量变更、模板 变更）、场景测试 管理员 ( 运维 ) 准备——工作 流 管理员 ( 运维 ) 准备——工作 流 面向角色 环境描述 环境名称样例 场景介绍 开发工程师 用于日常开发、联调 dev 如果 Java 栈实现灰度能力，可以通过新建环境随时拉 起开发自测子环境 如果采用 Istio + Skywalking 技术栈，通过 Zadig 开启自测模式随时拉起子环境 测试工程师 通知 Sprint 发布 测试验证 变更发布 产品规划 需求开发 Sprint 发布 测试验证 变更发布 产品规划 多人做集成联调——更新不同服务 启动 dev 工作流，选择多个服务和对应的 MR 执行 需求开发 多人做集成联调——更新同一个服务 启动 dev 工作流，选择多个服务以及其对应的多个 MR 执行 Sprint 发布 测试验证 变更发布 产品规划 需求开发 来 自 顶 级 资 本 的 多 轮 融 资 。 自 Z a d i g 2 0 2 1 年 开 源 以 来 ， 公 司 连 续 两 年 被 评 为 “ 开 源 中 国 ” 的 “ 年 度 优 秀 开 源 技 术 团 队 ” ， 2 0 2 2 年 度 3 6 氪 「 新 经 济 之 王 」 基 础 软 件 赛 道 的 “ 年 度 企 业 ” ， 2 0 2 2 年 度 G A D

今天，双核或者四核机器在多线程应用方面，其性能不见得的是单核机器的两倍或者四倍。 这一问题一直伴随 CPU 发展至今。 并发和并行的区别 • 运用多线程的方式和动机，一般分为两种。 • 并发：单核处理器，操作系统通过时间片调 度算法，轮换着执行着不同的线程，看起来 就好像是同时运行一样，其实每一时刻只有 一个线程在运行。目的：异步地处理多个不 同的任务，避免同步造成的阻塞。 • 并行：多核处理器，每个处理器执行一个线 核心数量，让系统调度保证各个核心始终饱和 • 因此，最好不是按照图像大小均匀等分，而是按照工 作量大小均匀等分。然而工作量大小我们没办法提前 知道……怎么办？ • 最简单的办法：只需要让线程数量超过 CPU 核心数量 ，这时操作系统会自动启用时间片轮换调度，轮流执 行每个线程。 • 比如这里分配了 16 个线程，但是只有 4 个处理器核心。 那么就会先执行 1,2,3,4 号线程，一段时间后自动切换 到 5,6,7,8 5.98 倍 并行筛选 6 使用 tbb::spin_mutex 替代 std::mutex 。 spin_mutex （基 于硬件原子指令）会让 CPU 陷入循环等待，而不像 mutex （操作系统提供调度）会让线程进入休眠状态的等待 。 若上锁的区域较小，可以用轻量级的 spin_mutex 。若上锁 的区域很大，则循环等待只会浪费 CPU 时间。这里锁的区 域是 std::copy ，比较大，所以

• 爱思考：为什么这里 Func 为 4 字节 ？ lambda 表达式：如何避免用模板参数 • 虽然 这样可以让编译器对 每个不同的 lambda 生成一次，有助于优 化。 • 但是有时候我们希望通过头文件的方式分 离声明和实现，或者想加快编译，这时如 果再用 template class 作为参数就不行了 。 • 为了灵活性，可以用 std::function 语言的 API 比如 pthread 和 atexit 。 lambda + 模板：双倍快乐 • 可以将 lambda 表达式的参数声明为 auto ，声明为 auto 的参数会自动根据调 用者给的参数推导类型，基本上和 template 等价。 • auto const & 也是同理，等价于模板函数 的 T const & 。 • 带 auto 参数的

std::milli> 的别名 跨平台的 sleep ： std::this_thread::sleep_for • 可以用 std::this_thread::sleep_for 替代 Unix 类操作系统专有的的 usleep 。他可 以让当前线程休眠一段时间，然后继续。 • 而且单位也可以自己指定，比如这里是 milliseconds 表示毫秒，也可以换成 microseconds 表示微秒， 除了接受一个时间段的 sleep_for ，还有 接受一个时间点的 sleep_until ，表示让当 前线程休眠直到某个时间点。 第 1 章：线程 进程与线程 • 进程是一个应用程序被操作系统拉起来加载到内存之后从开始执行到执行结束的这样一个 过程。简单来说，进程是程序（应用程序，可执行文件）的一次执行。比如双击打开一个 桌面应用软件就是开启了一个进程。 • 线程是进程中的一个实体 owns_lock() 判断是否上锁成功。 std::unique_lock ：用 std::adopt_lock 做参数 • 如果当前 mutex 已经上锁了，但是之后 仍然希望用 RAII 思想在解构时候自动调 用 unlock() ，可以用 std::adopt_lock 作 为 std::unique_lock 或 std::lock_guard 的第二个参数，这时他们会默认 mtx 已经 上锁。

表示不下，则自动选择较大的类型 标准化的类型： stdint.h • 而实际上，尽管主流操作系统上 int 都是 32 位的， C 语言标准并没有规定 int 就是 32 位 的。 • int 甚至可以是 16 位的！只不过主流操作系统一致认为是 32 位的而已，并不是标准所保 证的。 • 为了解决不同操作系统上对类型定义混乱的问题， C 语言标准引入了 stdint.h 这个头文件 。 • 他里面包含一系列类型别名 (typedef) ，这些别名保证不论是什么操作系统什么架构，都是 固定的大小，例如： • typedef char int8_t; • typedef short int16_t; • typedef int int32_t; • typedef long long int64_t; • 这样不论操作系统对类型的定义如何混乱，这些标准化的类型都是确定的大小。 • 这个直观的名字，他和 uintptr_t 等价 。 • size_t 是标准库大量使用的用于表示大小的类型，例如 vector::size() 返回类型就是 size_t 。 • 在主流操作系统上， size_t 和 uintptr_t 完全等价，虽然标准并没有强制要求这一点。 • 此外还有有符号的 ssize_t 和 intptr_t 等价，不过他是 Unix/Linux 系统特有的，