分为前半段和后半段，前半段主要介绍现代 C++ ，后半段主要介绍并行编程与优化。 1.课程安排与开发环境搭建： cmake 与 git 入门 2.现代 C++ 入门：常用 STL 容器， RAII 内存管理 3.现代 C++ 进阶：模板元编程与函数式编程 4.编译器如何自动优化：从汇编角度看 C++ 5.C++11 起的多线程编程：从 mutex 到无锁并行 6.并行编程常用框架： OpenMP 们来点（相对）简单的作为饭后甜点吧！ C++98 ：令人头疼的内存管理 • 在没有智能指针的 C++ 中，我们只能手 动去 new 和 delete 指针。这非常容易出 错，一旦马虎的程序员忘记释放指针，就 会导致内存泄露等情况，更可能被黑客利 用空悬指针篡改系统内存从而盗取重要数 据等。 RAII 解决内存管理的问题： unique_ptr • 似曾相识的情形……是的，和我们刚刚提 放时。比如：指向窗口中上一次被点击的元素。 5. 初学者可以多用 shared_ptr 和 weak_ptr 的组合，更安全。 shared_ptr 管理的对象生命周期，取决于所有引用中，最长寿的那一个。 unique_ptr 管理的对象生命周期长度，取决于他所属的唯一一个引用的寿命 。 那是不是只要 shared_ptr 就行，不用 unique_ptr 了？ • 可以适当使用减轻初学者的压力，因为他的行为和

现代 CMake 模块化项目管理指南 彭于斌（ @archibate ） 课件 & 源码： https://github.com/parallel101/course 往期录播： https://space.bilibili.com/263032155 找不到头文 件怎么办呀 CMake Cookbook 小彭老师建议 : ~~-·~·~-·~ -~·-·~·- 第一章：文件 / 关键 字。 八、每新增一个功能模块，需要创建两个文件 • 添加一个新功能模块 Carer 时，同时添加同名的源文件和头文 件。 • 头文件中的声明和源文件中的实现一一对应。 九、一个模块依赖其他模块，则应导入他的头文件 • 如果新模块（ Carer ）中用到了其他模块（ Animal ）的类或函数，则需要 在新模块（ Carer ）的头文件和源文件中都导入其他模块（ Animal ）的头 注意不论是项目自己的头文件还是外部的系统的头文件，请全部统一采用 < 项目名 / 模块名 .h> 的格式。不要用 “模块名 .h” 这种相对路径的格式，避 免模块名和系统已有头文件名冲突。 十、依赖其他模块但不解引用，则可以只前向声明不导入头文件 • 如果模块 Carer 的头文件 Carer.h 虽然引用了其他模块中的 Animal 类，但 是他里面并没有解引用 Animal ，只有源文件

分为前半段和后半段，前半段主要介绍现代 C++ ，后半段主要介绍并行编程与优化。 1.课程安排与开发环境搭建： cmake 与 git 入门 2.现代 C++ 入门：常用 STL 容器， RAII 内存管理 3.现代 C++ 进阶：模板元编程与函数式编程 4.编译器如何自动优化：从汇编角度看 C++ 5.C++11 起的多线程编程：从 mutex 到无锁并行 6.并行编程常用框架： OpenMP 文件越来越多时，一个个调用 g++ 编译链接会变得很麻烦。 • 于是，发明了 make 这个程序，你只需写出不同文件之间的依赖关系，和生成各文件的规则。 • > make a.out • 敲下这个命令，就可以构建出 a.out 这个可执行文件了。 • 和直接用一个脚本写出完整的构建过程相比， make 指明依赖关系的好处： 1. 当更新了 hello.cpp 时只会重新编译 hello.o ，而不需要把 main o 重复写 g++ 命令（ %.o: %.cpp ）。 • 但坏处也很明显： 1. make 在 Unix 类系统上是通用的，但在 Windows 则不然。 2. 需要准确地指明每个项目之间的依赖关系，有头文件时特别头疼。 3. make 的语法非常简单，不像 shell 或 python 可以做很多判断等。 4. 不同的编译器有不同的 flag 规则，为 g++ 准备的参数可能对 MSVC

部署预发环境 xN 部署生产环境 xN 部署 / 灰度上线 xN 监控 / 告警 xN 版本归档 xN 交付追踪 xN 数据度量 xN 服务、工单管理 事件、缺陷管理 想 法 用 户 运行阶段 需求阶段 研发阶段 现代软件交付挑战：开发 5 分钟，上线 2 小时 服务一：设计 | 代码编写 | 构建 | 服务全生命周期而非只关注代码 ● 每天多次提交提早验证 Zadig 采用「云原生产品级交付」设计理念 数字化产研协同 • 环境 - 统一开发者协作平面 • 工作流 - 统一交付变更通道 • 异构支持 - 统一产研运管理平面 重视开发者体验，工程师不再做脏活累活 传统 DevOps 体系 Zadig 云原生 DevOps 平台 高人效 低人效 低人效 / 低质量 / 低效率 / 高成 本： 人淹没在系统的海洋里，无数平台手工切换 研发透明化：不同项目清晰可见的效率、质量、进度 进度管理：根据团队客观数据，预测和确定项目规划 迭代进度一目了然 项目从无到有可核算 管理有数据科学依据 解放管理，更多时间花在 业务创新 平台运维 业务压力大，能力建设缓慢： • 大量工作花在工具链维护 • 项目间依赖复杂，环境管理难 • 交付版本依赖工单，发布风险高 • 公共资源 / 业务资源利用率低 赋能多业务：一个平台解决了多异构项目的管理和规范 团队高效协作

这个构建系统的构 建规则。 Ninja 是一个高性能，跨平台的构建系统， Linux 、 Windows 、 MacOS 上都可 以用。 • Ninja 可以从包管理器里安装，没有包管理器的 Windows 可以用 Python 的包管理器安 装： • pip install ninja （有趣的事实： CMake 也可以通过 pip install cmake 安装……） • 事实上， MSBuild 在其他目录，因此 Windows 会找不到 dll 。 • 解决 1 ：把 dll 所在位置加到你的 PATH 环境变量里去，一劳永逸。 • 解决 2 ：把这个 dll ，以及这个 dll 所依赖的其他 dll ，全部拷贝到和 exe 文件同一目录 下。 手动拷贝 dll 好麻烦，能不能让 CMake 把 dll 自动生成在 exe 同一 目录？ • 归根到底还是因为 CMake 把定义在顶层模块里的 /usr/lib/cmake/TBB/TBBConfig.cmake 长啥样？ 不论是 TBBConfig.cmake 还是 FindTBB.cmake ，这个文件通常 由库的作者提供，在 Linux 的包管理器安装 tbb 后也会自动安装 这个文件。少部分对 CMake 不友好的第三方库，需要自己写 FindXXX.cmake 才能使用。 老年项目案例： OpenVDB （反面教材） 一些老年项目作者喜欢在项目里自己塞几个

分为前半段和后半段，前半段主要介绍现代 C++ ，后半段主要介绍并行编程与优化。 1.课程安排与开发环境搭建： cmake 与 git 入门 2.现代 C++ 入门：常用 STL 容器， RAII 内存管理 3.现代 C++ 进阶：模板元编程与函数式编程 4.编译器如何自动优化：从汇编角度看 C++ 5.C++11 起的多线程编程：从 mutex 到无锁并行 6.并行编程常用框架： OpenMP 构建目标的 cmake 项目，有病啊！ 你妨碍别人作为子模块用你的项目。没错说的就是你 OpenSim ，张心欣当时浪费好多时间伺候这个沙雕库。 还要指定一个环境变量 SIMBODY_HOME 指向他的依赖项 SimBody 的源码路径，这么 dedicated 让人咋 用？ 第 4 章：任务域与嵌套 https://link.springer.com/chapter/10.1007%2F978-1-4842-4398-5_12 队列里取出数据，即“认领任务”。然后执行，执行 完毕后才去认领下一个任务，从而即使每个任务 工作量不一也能自动适应。 • 这种技术又称为线程池（ thread pool ），避免了 线程需要保存上下文的开销。但是需要我们管理 一个任务队列，而且要是线程安全的队列。 struct Task { int x0, y0; int nx, ny; }; std::queue q; 1 2 3 4

API 和这个很像，但毕竟没有 CUDA 可以直接在核函数里调用核函数并指定参数这么方便…… 不过，这个功能同样需要开启 CUDA_SEPARABLE_COMPILATION 。 第 2 章：内存管理 如何从核函数里返回数据？ • 我们试着把 kernel 的返回类型声明为 int ，试 图从 GPU 返回数据到 CPU 。 • 但发现这样做会在编译期出错，为什么？ • 刚刚说了 kernel 循环迭代所有 1024 个元 素，实际上内部仍然是一个串行的过程，数据是强烈 依赖的（ local_sum += arr[j] 可以体现出，下一时刻 的 local_sum 依赖于上一时刻的 local_sum ）。 • 要消除这种依赖，可以通过右边这样的逐步缩减，这 样每个 for 循环内部都是没有数据依赖，从而是可以 并行的（对 CPU 而言是 SIMD 和指令级并行，虽 然 GPU 循环迭代所有 1024 个元 素，实际上内部仍然是一个串行的过程，数据是强烈 依赖的（ local_sum += arr[j] 可以体现出，下一时刻 的 local_sum 依赖于上一时刻的 local_sum ）。 • 要消除这种依赖，可以通过右边这样的逐步缩减，这 样每个 for 循环内部都是没有数据依赖，从而是可以 并行的（对 CPU 而言是 SIMD 和指令级并行，虽 然 GPU

• 这样一次随机访问之后会伴随着 64 次顺序访问， 能被 CPU 检测到，从而启动缓存行预取，避免了 等待数据抵达前空转浪费时间。 页对齐的重要性 • 为什么要 4KB ？原来现在操作系统管理内存是用分页 （ page ），程序的内存是一页一页贴在地址空间中的， 有些地方可能不可访问，或者还没有分配，则把这个页设 为不可用状态，访问他就会出错，进入内核模式。 • 因此硬件出于安全，预取不能跨越页边界，否则可能会触 给数组分配内存，是内核执 行内存分配的这个动作，花费了额外的时间。而第二次因为内存已经被分配上了，所以再 次访问也不会触发缺页中断，所以看起来比第一次快很多。 进一步：分配是按页面（ 4KB ）来管理的 • 当一个尚且处于“不可用”的 malloc 过的区间被访问，操作系统不是把整个区间全部分配完 毕，而是只把当前写入地址所在的页面（ 4KB 大小）给分配上。也就是说用户访问 a[0] 以后只分配了 #ifdef WITH_TBB 包围住需 要用到 tbb 的部分，这样即使没有 tbb 的同学也能 正常编译其他没有 tbb 的 benchmark 。 • 毕竟微软的钱全用在买暴雪上了，没钱搞包管理器。 实战案例：矩阵乘法 • 分析访存规律： • a(i, j) 始终在一个地址不动（一般）。 • b(i, t) 每次跳跃 n 间隔的访问（坏）。 • c(t, j) 连续的顺序访问（好）。

Management On JDOS 梁永清 liangyongqing1@jd.com 提供的服务 1. 用于实验的 GPU 容器 2.基于 Kubeflow 的机器学习训练服务 3.模型管理和模型 Serving 服务 Experiment Training Serving 均基于容器，不对业务方直接提供 GPU 物理机 GPU 实验 JDOS 常规的容器服务 ，使用 gpu 的 zone ， 自行设定相应的镜像即 可，有完善的周边服务 训练服务 • 提供基于 kubeflow 的分布式训练方案 – 界面化操作，用户提供代码地址和执行命令即可 – 系统内建支持安装 pip 依赖 – 自制存储插件支持分布式文件系统存储用户数据 – 支持官方镜像，不需要 JDOS 提前协助制作镜像 – 提供 tensorboard 作为训练监控实时查看训练状态 – 用户训练完成后释放

size_t func_calc_size(); • void func(T* data); • 第一个函数预先计算出大小，第二个函数才实际把值写入到数组。 • 也可以把他们融合成一个函数方便管理： • size_t func(T* data); • 第一遍先调用 func(NULL) 获取长度。然后用 malloc 分配相应长度的内存，然后第二遍 实际把数据写入到你分配的数组。这样就不需要让 这样函数退出时不会释放数组，调用者就 可以访问到正确的数据了。 • 当然这样需要调用者在退出时手动调用一 下 free(a) ，因为堆内存不会自动释放。 太复杂了？没关系，用 C++ 的容器库 • 如果你觉得这样自己管理内存太麻烦了，那是 正常的。对于不精通 C 语言的小白程序员来 说，很容易就忘记释放内存了。 • 因此 C++ 提供了符合 RAII 思想的 vector 容器，他会在自己解构时自动释放内存。 • 这其实是一个巧合，由于编译器会把相同 的字符串自动放在同样的位置以便节省存 储空间，所以两个字符串指针刚好指向了 同样的地址。 常见错误：以为是值比较，其实是指针比较 • 但是你不能依赖这种巧合，如果两个字符 串是在栈上分配的数组，那么首地址就不 一样，从而始终会返回 false 了。 • 刚才编译器分配的空间实际上是在全局空 间，和可执行文件放在一块（相当于全局 变量）。现在这样是在栈空间，不一样了