许多朋友曾经与我讨论过，对于MFC 这类application framework，应该挖掘其内部机制到什 么程度？探究源代码，岂不有违「黑盒子」初衷？但是，没有办法，他们也同意，不把那些 奇奇怪怪的宏和指令搞清楚，只能生产出玩具来。对付MFC 内部机制，态度不必像对付 MFC 类别一样；你只需好好走过那么一回，有个印象，足矣。至于庞大繁复的整个application framework 技术的铺陈 本书光盘片内含书中所有的范例程序，包括源代码与EXE 档。中介文件（如.OBJ 和.RES 等）并未放入。所有程序都可以在Visual C++ 5.0 整合环境中制作出来。安装 方式很简单（根本没有什么安装方式）：利用DOS 外部指令，XCOPY，把整个光盘片 拷贝到你的硬盘上即是了。 范例程序说明 ■ Generic（第１章）：这是一个Win32 程序，主要用意在让大家了解Win32 程 式的基本架构。 ■ Jb CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) 注意，不论什么消息，都必须被处理，所以switch/case 指令中的default: 处必须调用 DefWindowProc，这是Windows 内部预设的消息处理函数。 窗口函数的wParam 和lParam 的意义，因消息之不同而异。wParam 在16

分支预测成败对性能的影响 排序为什么对有分支的版本影响那么大 为什么需要流水线 • 为了高效， CPU 的内部其实是一个流水 线 (pipeline) 。流水线的目的是能把原本 串行的一系列指令并行化。为了理解为什 么需要流水线，我们先反过来，假设没有 流水线，会有什么坏处。 • 例如，右边你今天早上的任务清单。 • 请问你这些任务总共需要多少时间？ 任务 时间 占用资源 洗脸 钟嘛！可以，不过这是在你每次只做一件 事的情况下，例如你烧开水时就站在旁边 干瞪眼，什么也不做，其实完全可以在烧 开水的同时洗脸刷牙呀！原始的 CPU 也 是这样， ALU 在运算的时候指令解码单元 就在旁边干瞪眼，要等 ALU 跑完写回寄 存器来指令解码单元才开始继续工作，很 低效。 任务 时间 占用资源 洗脸 5 分钟 眼睛，嘴巴，手 烧开水 10 分钟 煤气灶 刷牙 5 分钟 嘴巴，手 看比站 15 刷牙 烧开水 吃饭 看比站 拉粑粑 5 5 10 20 条件跳转指令 • 让不占用相同资源的任务同时进行，这也是 CPU 流水线的初衷。但理想是美好的，现实 是骨感的，对于程序来说，指令不只是一个 个简单的任务，有时候我们需要做判断，来 决定要执行的具体任务，这就是分支，在汇 编语言中体现为条件跳转指令。 • 例如我们这里给任务清单加一个，如果烧开 水时被烫伤，则直接去医院的特殊任务。

免从外部内存读写的超高延迟。 缓存的分级结构 查看高速缓存大小： lscpu • 可以看到我们 x86 电脑的缓存结构分为三级。 • 一级缓存分为数据缓存和指令缓存，其中数据缓存有 32 KB ， 6 个物理核心每个都有一个，总共 192 KB 。而指令缓存的大小刚好和数据缓存一样也是 192 KB 。 • 二级缓存有 256 KB ， 6 个物理核心每个都有一个， 总共 1.5 MB 。 缓存行预取技术：吃着一碗饭的同时，先喊妈妈烧下一碗饭 • 其实，当程序顺序访问 a[0], a[1] 时， CPU 会智能地预测到你接下来可 能会读取 a[2] ，于是会提前给缓存发送一个读取指令，让他读取 a[2] 、 a[3] 。缓存在后台默默读取数据的同时， CPU 自己在继续处理 a[0] 的数据。这样等 a[0], a[1] 处理完以后，缓存也刚好读取完 a[2] 了，从而 申请起始地址对齐到页边 界的一段内存，真正做到每个块内部不出现跨页现象。 手动预取： _mm_prefetch • 对于不得不随机访问很小一块的情况，还可以通过 _mm_prefetch 指令手动预取一个缓存行。 • 这里第一个参数是要预取的地址（最好对齐到缓存 行），第二个参数 _MM_HINT_T0 代表预取数据 到一级缓存， _MM_HINT_T1 代表只取到二级缓 存， _MM_HINT_T2

%rsi), %eax 相当于： eax = &*(rdi + rsi) 妙用本用于指针的指令，尽管此时 rdi 和 rsi 并不是指针 整数加常数乘整数：都可以被优化成 leal 因为这种线性变换在地址索引 中很常见，所以被 x86 做成 了单独一个指令。这里尽管不 是地址，但同样可以利用 lea 指令简化生成的代码大小。 eax = rdi + rsi * 8 指针访问对象：线性访问地址 省流助手： 如果你看到编译器生成的汇编里，有大量 ss 结尾 的指令则说明矢量化失败；如果看到大多数都是 ps 结尾则说明矢量化成功。 xmm0 xmm1 xmm0 addss %xmm1, %xmm0 addps %xmm1, %xmm0 xmm0 xmm1 xmm0 为什么需要 SIMD ？单个指令处理四个数据 • 这种单个指令处理多个数据的技术称为 SIMD （ single-instruction 在一定条件下，编译器能够把一个处理标量 float 的代码，转换成一个利用 SIMD 指令的 ，处理矢量 float 的代码，从而增强你程序的吞吐能力！ • 通常认为利用同时处理 4 个 float 的 SIMD 指令可以加速 4 倍。但是如果你的算法不 适合 SIMD ，则可能加速达不到 4 倍；也有因为 SIMD 让访问内存更有规律，节约了指 令解码和指令缓存的压力等原因，出现加速超过 4 倍的情况。 第 1 章：化简

__host__ 和 __device__ 。 通过 #ifdef 指令针对 CPU 和 GPU 生成不同的代码 • CUDA 编译器具有多段编译的特点。 • 一段代码他会先送到 CPU 上的编译器（通常是系统自带的编译 器比如 gcc 和 msvc ）生成 CPU 部分的指令码。然后送到真 正的 GPU 编译器生成 GPU 指令码。最后再链接成同一个文件 ，看起来好像只编译了一次一样，实际上你的代码会被预处理很 这个变量 ，设置要针对哪个架构生成 GPU 指令码。 • 小彭老师的显卡是 RTX2080 ，他的版本号是 75 ，因 此最适合他用的指令码版本是 75 。 • 如果不指定，编译器默认的版本号是 52 ，他是针对 GTX900 系列显卡的。 • 不过英伟达的架构版本都是向前兼容的，即版本号为 75 的 RTX2080 也可以运行版本号为 52 的指令码，虽然 不够优化，但是至少能用。也就是要求：编译期指定的 降低除法的精度换取速度。 • --prec-sqrt=false 降低开方的精度换取速度。 • --fmad 因为非常重要，所以默认就是开启的， 会自动把 a * b + c 优化成乘加 (FMA) 指令。 • 开启 --use_fast_math 后会自动开启上述所有。 SAXPY （ Scalar A times X Plus Y ） • 即标量 A 乘 X 加 Y 。 • 这是很多 CUDA

（概念）。比起虚函数和 动态多态的接口抽象， concept 使实现和接口更加解 耦合且没有性能损失。 第 4 章：死锁 同时锁住多个 mutex ：死锁难题 • 由于同时执行的两个线程，他们中发生的指令不 一定是同步的，因此有可能出现这种情况： • t1 执行 mtx1.lock() 。 • t2 执行 mtx2.lock() 。 • t1 执行 mtx2.lock() ：失败，陷入等待 counter += i 在 CPU 看来会变成三个指令： 1. 读取 counter 变量到 rax 寄存器 2. rax 寄存器的值加上 1 3. 把 rax 写入到 counter 变量 • 即使编译器优化成 add [counter], 1 也没用，因为现代 CPU 为了高效，使用了大量奇技淫巧，比如他会把一 条汇编指令拆分成很多微指令 (micro-ops) ，三个甚至 有点保守估计了。 如果是这种顺序，最后 t1 的写入就被 t2 覆盖了，从而 counter 只增加了 1 ，而没有像预期的那样增加 2 。 • 更不用说现代 CPU 还有高速缓存，乱序执行，指令级并行等 优化策略，你根本不知道每条指令实际的先后顺序。 暴力解决：用 mutex 上锁 • 这样的确可以防止多个线程同时修改 counter 变量，从而不会冲突。 • 问题： mutex 太过重量级，他会让线程被

先对 a 预留一定的内存，避免频繁扩容影响性能。 加速比： 5.98 倍 并行筛选 6 使用 tbb::spin_mutex 替代 std::mutex 。 spin_mutex （基 于硬件原子指令）会让 CPU 陷入循环等待，而不像 mutex （操作系统提供调度）会让线程进入休眠状态的等待 。 若上锁的区域较小，可以用轻量级的 spin_mutex 。若上锁 的区域很大，则循环等待只会浪费 ch 替代？ 简单粗暴并行 for 加速比： 3.16 倍 很不理想，为什么？ 很简单，循环体太大，每跑一遍指令缓存和数据缓存都 会重新失效一遍。且每个核心都在读写不同地方的数据 ，不能很好的利用三级缓存，导致内存成为瓶颈。 拆分为三个 for 加速比： 3.47 倍 解决了指令缓存失效问题，但是三次独立的 for 循环每次 结束都需要同步，一定程度上妨碍了 CPU 发挥性能；而 且每个 step 后依然写回了数组，数据缓存没法充分利用 。 另辟蹊径：流水线并行 加速比： 6.73 倍 反直觉的并行方式，但是加速效果却很理想，为什么？ 流水线模式下每个线程都只做自己的那个步骤（ filter ），从 而对指令缓存更友好。且一个核心处理完的数据很快会被另一 个核心用上，对三级缓存比较友好，也节省内存。 且 TBB 的流水线，其实比教科书上描述的传统流水线并行更加优化： 他在 t1 线程算完 d1 的 s1

Makefile • 执行本地的构建系统 make 真正开始构建（ 4 进程并 行） • 让本地的构建系统执行安装步骤 • 回到源码目录 现代 CMake 提供了更方便的 -B 和 --build 指令，不同平台，统一命 令！ • cmake -B build • cmake --build build -j4 • sudo cmake --build build --target install 则关闭 GCC 的扩展功能，只使用标准的 C++ 。 • 要兼容其他编译器（如 MSVC ）的项目，都会设为 OFF 防止不小心用了 GCC 才有的 特性。 • 此外，最好是在 project 指令前设置 CMAKE_CXX_STANDARD 这一系列变量，这样 CMake 可以在 project 函数里对编译器进行一些检测，看看他能不能支持 C++17 的特 性。 https://crascit cmake_minimum_required 不仅是“最小所需版本” 虽然名字叫 minimum_required ，实际上不光是 >= 3.15 就不出错这么简单。 根据你指定的不同的版本号，还会决定接下来一系列 CMake 指令的行为。 此外，你还可以通过 3.15...3.20 来表示最高版本不超过 3.20 。 这会对 cmake_policy 有所影响，稍后再提。 https://runebook.dev/zh-C

5。但实际情况远比此复杂得多，或者说这段代码本身属于未定义的行为，因 为对于 a 和 flag 而言，他们在两个并行的线程中被读写，出现了竞争。除此之外，即便我们忽略竞争 读写，仍然可能受 CPU 的乱序执行，编译器对指令的重排的影响，导致 a = 5 发生在 flag = 1 之后。 从而 b 可能输出 0。 68 7.5 原子操作与内存模型 第 7 章并行与并发 原子操作 std::mutex 可以解决 进行隔离 这是一组非常强的同步条件，换句话说当最终编译为 CPU 指令时会表现为非常多的指令（我们之 后再来看如何实现一个简单的互斥锁）。这对于一个仅需原子级操作（没有中间态）的变量，似乎太苛刻 了。 关于同步条件的研究有着非常久远的历史，我们在这里不进行赘述。读者应该明白，现代 CPU 体系 结构提供了 CPU 指令级的原子操作，因此在 C++11 中多线程下共享变量的读写这一问题上，还引入了 中多线程下共享变量的读写这一问题上，还引入了 std::atomic 模板，使得我们实例化一个原子类型，将一个原子类型读写操作从一组指令，最小化到单 个 CPU 指令。例如： std::atomic counter; 并为整数或浮点数的原子类型提供了基本的数值成员函数，举例来说，包括 fetch_add, fetch_sub 等，同时通过重载方便的提供了对应的 +，- 版本。比如下面的例子： #include

unsigned 类型的 >> n 会不会复制最高位， 只是单纯的位移，这会导致负数的符号位单独被位 移，补码失效，造成结果不对。 unsigned 类型的 >> 会生成 shr 指令， signed 类型的 >> 会生成 sar 指令。 我们需要负方向无限延伸的稀疏数据结果，那就只 要 signed 那个就行。 >> 2 = 没有重合时可以用高效的加法：位运算 | • 如果可以保证 a 和 b ）不一定就是完美解决方案，要根据实际情况判断。 真正的解决： tbb::spin_mutex 其实主要的瓶颈在于 std::mutex 会切换到操作系统内核中去调度 ，非常低效。而 tbb::spin_mutex 则是基于硬件原子指令的，完全 用户态的实现。区别： std::mutex 的陷入等待会让操作系统挂起 该线程，以切换到另一个；而 tbb::spin_mutex 的陷入等待是通过 不断地 while (locked);