生成两份源码级不同的 代码。 __CUDA_ARCH__ 是个版本号 • 其实 __CUDA_ARCH__ 是一个整数，表 示当前编译所针对的 GPU 的架构版本号 是多少。这里是 520 表示版本号是 5.2.0 ，最后一位始终是 0 不用管，我们 通常简称他的版本号为 52 就行了。 • 这个版本号是编译时指定的版本，不是运 行时检测到的版本。编译器默认就是最老 的 52 ，能兼容所有 GTX900 CMake 设置架构版本号 • 可以用 CMAKE_CUDA_ARCHITECTURES 这个变量 ，设置要针对哪个架构生成 GPU 指令码。 • 小彭老师的显卡是 RTX2080 ，他的版本号是 75 ，因 此最适合他用的指令码版本是 75 。 • 如果不指定，编译器默认的版本号是 52 ，他是针对 GTX900 系列显卡的。 • 不过英伟达的架构版本都是向前兼容的，即版本号为 75 的 RTX2080 也可以运行版本号为 52 的指令码，虽然 不够优化，但是至少能用。也就是要求：编译期指定的 版本 ≤ 运行时显卡的版本。 CMAKE_CUDA_ARCHITECTURES 会自动转换成 --gpu-code 等编 译 flag 版本号不要太新了 • 比如这里设置了 RTX3000 系列的架构版 本号 86 ，在 RTX2080 上就运行不出结 果。 • 最坑的是他不会报错！也不输出任何东西

器处理寄存器翻车（ register spill ）的压力。 • 因此 64 位比 32 位机器相比，除了内存突破 4GB 限制外，也有一定性能优势。 8 位， 16 位， 32 位， 64 位版本 al, ax, eax, rax r15b, r15w, r15d, r15 AT&T 汇编语言 GCC 编译器所生成的汇编语言就属于这种 返回值：通过 eax 传出 movl $42, %eax 有所谓的“老师”就不肯动动手敲几行命令（写 doc 文件倒挺勤的），在那里传播假知识。 • 在线做编译器实验推荐这个网站： https://godbolt.org/ • 可以实时看源代码编译的结果，还能选不同的编译器版本和 flag 。 • 不要脑内模拟！你误以为某更改对性能有帮助，然而实际测一下时间有一定可能反而变慢 。 第 3 章：指针 编译器傻了吗？ 为什么编译器不优化掉 *c = *a ？ 指针别名现象（ 而我们可以用 const 禁止写入访问。 结论：所有非 const 的指针都声明 __restrict 。 禁止优化： volatile 结论：加了 volatile 的对象，编 译器会放弃优化对他的读写操作 。 做性能实验的时候非常有用。 注意一下区别 1. volatile int *a 或 int volatile *a 2. int *__restrict a • 语法上区别： volatile

cudaSurfaceObject_t ）。 • 考虑到多维数组始终是需要通过表面对象来访问的，这 里我们让表面对象继承自多维数组。 • 在核函数中可以用 surf3Dread 和 surf3Dwrite 来读写 表面对象中的元素， x,y,z 参数指定要访问元素的坐标 ，要注意 x 必须乘以 sizeof( 元素类型 ) ，否则出错。 • 这里用了访问者模式（ Accessor ， GPU 编程常用）。 编程常用）。 原来的 CudaSurface 管理资源，禁止拷贝。然后单独 弄一个访问者类 CudaSurfaceAccessor ，不管理资源 ，仅仅是指向资源的一个弱引用，可以随意拷贝。并把 读写访问的方法（ surf3Dread ）定义在访问者类。 CUDA 表面对象：封装 • 此外，表面对象还支持自动判断 x,y,z 坐标是否越界 ， surf3Dread/write 的最后一个参数，用于指定出现 ） • 这里我参考了 Taichi 官方案例中的 stable_fluid.py 代码（二维定常流仿真），主要由 k-ye 编写 ，我学习 GAMES201 后贡献了支持 RK2 和 RK3 的版本。这里我们用高效的 CUDA 纹理对象 在 C++ 中重新实现了一遍，利用了硬件的三线性插值实现半拉格朗日（ semi-lagrangian ）对流。 对流部分：根据对流后位置重新采样 • 和

com/parallel101/course 为什么往 int 数组里赋值 1 比赋值 0 慢一倍？ 第 1 章：内存带宽 cpu-bound 与 memory-bound • 通常来说，并行只能加速计算的部分，不能加速内存读写的部分 。 • 因此，对 fill 这种没有任何计算量，纯粹只有访存的循环体，并 行没有加速效果。称为内存瓶颈（ memory-bound ）。 • 而 sine 这种内部需要泰勒展开来计算，每次迭代计算量很大的 在太少了。 • 计算太简单，数据量又大，并行只带来了多线程调度的额外开销 。 • 小彭老师经验公式： 1 次浮点读写 ≈ 8 次浮点加法 • 如果矢量化成功（ SSE ）： 1 次浮点读写 ≈ 32 次浮点加法 • 如果 CPU 有 4 核且矢量化成功： 1 次浮点读写 ≈ 128 次浮点加 法 常见操作所花费的时间 • 图中加法 (add) 和乘法 (mul) 都指的整数。 • 用了 6 核才饱和。 • 结论：要想利用全部 CPU 核心，避免 mem-bound ，需要 func 里有足够的计算 量。 • 当核心数量越多， CPU 计算能力越强，相 对之下来不及从内存读写数据，从而越容 易 mem-bound 。 1 2 4 6 8 10 0 50 100 150 200 250 300 350 funcA funcB funcC 内存信息查看工具：

。 • 所以， download 函数才会出师未捷身先死 ——还没开始执行他的线程就被销毁了。 解构函数不再销毁线程： t1.detach() • 解决方案：调用成员函数 detach() 分离该 线程——意味着线程的生命周期不再由当 前 std::thread 对象管理，而是在线程退 出以后自动销毁自己。 • 不过这样还是会在进程退出时候自动退出 。 解构函数不再销毁线程：移动到全局线程池 mutex 作为参数，并且 他保证在无论任意线程中调用的顺序是否 相同，都不会产生死锁问题。 std::lock 的 RAII 版本： std::scoped_lock • 和 std::lock_guard 相对应， std::lock 也 有 RAII 的版本 std::scoped_lock 。只不 过他可以同时对多个 mutex 上锁。 同一个线程重复调用 lock() 也会造成死锁 上仍是 const 的。因此，为了让 this 为 const 时仅仅给 m_mtx 开后门，可以用 mutable 关键字修饰他，从而所有成员里 只有他不是 const 的。 为什么需要读写锁？ • 刚才说过 mutex 就像厕所，同一时刻只有一个人能上。但是如果“上”有两种方式呢？ • 假设在平行世界，厕所不一定是用来拉的，还可能是用来喝的（只是打个比方，请勿尝试） • 喝厕所里的水时，可以多个人插着吸管一起喝。

之间的区别）。在编写 C++ 时，也应该尽可能 的避免使用诸如 void* 之类的程序风格。而在不得不使用 C 时，应该注意使用 extern "C" 这种特性， 将 C 语言的代码与 C++ 代码进行分离编译，再统一链接这种做法，例如： // foo.h #ifdef __cplusplus extern "C" { #endif int add(int x, int y); #ifdef len_foo() 在运行期实际上是返 回一个常数，这也就导致了非法的产生。 注意，现在大部分编译器其实都带有自身编译优化，很多非法行为在编译器优化的加持下会 变得合法，若需重现编译报错的现象需要使用老版本的编译器。 C++11 提供了 constexpr 让用户显式的声明函数或对象构造函数在编译期会成为常量表达式，这 个关键字明确的告诉编译器应该去验证 len_foo 在编译期就应该是一个常量表达式。 == 1) return 1; if(n == 2) return 1; return fibonacci(n-1) + fibonacci(n-2); } 为此，我们可以写出下面这类简化的版本来使得函数从 C++11 开始即可用： constexpr int fibonacci(const int n) { return n == 1 || n == 2 ? 1 : fibonacci(n-1)

则停留在4.2，程序设计 的主轴没有什么大改变。对于新读者，本书乃全新产品自不待言，您可以从目录中细细琢磨 所有的主题。对于老读者，本书所带给您的，是更精致的制作，以及数章新增的内容（请看 第０章「与前版本之差异」）。 6 最后，我要说，我知道，这本书真的带给许多人很扎实的东西。而我所以愿意不计代价去做 些不求近利的深耕工作，除了这是身为专业作家的责任，以及个人的兴趣之外，是的，我自 己是工程师，我最清楚工程师在学习MFC 新竹1997.04.15 jjhou@ccca.nctu.edu.tw FAX 886-3-5733976 7 第一版序 有一种软件名曰version control，用来记录程序开发过程中的各种版本，以应不时之需，可以 随时反省、检查、回复过去努力的轨迹。 遗憾的是人的大脑没有version control 的能力。学习过程的彷徨犹豫、挫折困顿、在日积月 累的渐悟或x那之间的顿悟之后，彷 讓我們使用同㆒種語言 / 30 本書符號習慣 / 34 磁片內容與安裝 / 34 範例程式說明 / 34 與前版本之差異 / 39 如何聯絡作者 / 40 第㆒篇 勿在浮砂築高臺 - 本書技術前提 / 001 第１章 Win32 程式基本觀念/ 003 Win32 程式開發流程/ 005

疏网格、位运算、浮点的二进制格式、内存带宽优 化 面向人群：图形学、 CFD 仿真、深度学习编程人 员 第 0 章：稀疏矩阵 稠密数组存储矩阵 用 foreach 包装一下枚举的过程 改用 map 来存储 分离 read/write/create 三种访问模式 foreach 直接给出当前坐标指向的值 改用 unordered_map 来存储 unordered_map 手动 read(i, j) 也一样速度 int64_t ：每个占据 8 字节 • 如果用更大的数据类型，用时会直接提升两倍！ • 这是因为 i % 2 的计算时间，完全隐藏在内存 的超高延迟里了。 • 可见，当数据量足够大，计算量却不多时，读写 数据量的大小唯一决定着你的性能。 • 特别是并行以后，计算量可以被并行加速，而访 存却不行。 使用 int8_t ：每个占据 1 字节 • 因此我们可以把数据类型变小，这样所需的内存 量就变小，从而内存带宽也可以减小！ n 位为 1 。 • bits |= 0 << n; • 则没有任何改变。 std::vector ：标准库帮你实现好了 • 其实标准库的 vector 是一个特化的版本 ，他会自动像刚刚说的把值看做 1bit ，然后八个 合并成一个 int8_t 。 • 不过效率比我们手写的低很多…… 不推荐使用 std::vector • 不建议使用 vector

这种情况出现时，就意味着你需要把成员变量的读写封装为成员函数 不变性：请勿滥用封装 • 仅当出现“修改一个成员时，其他也成员要 被修改，否则出错”的现象时，才需要 getter/setter 封装。 • 各个成员之间相互正交，比如数学矢量类 Vec3 ，就没必要去搞封装，只会让程序员 变得痛苦，同时还有一定性能损失：特别 是如果 getter/setter 函数分离了声明和定 义，实现在另一个文件时！

这是因为内存是一维排列的，假如内存容量是 65536 字节，那所谓的内存地址实际上就 是一个从 0 到 65535 范围的整数，也就是两个字节组成的字。 • 处理器去读写内存的时候靠的是寄存器提供的地址，因此寄存器的大小（也就是字的大 小）决定了他能读写的内存大小，例如： • 由于 16 位计算机的寄存器只能存储 16 位，他只能访问 65536 字节（ 64 KB ）的内存 。 • 由于 32 位计算机的寄存器只能存储 之外的其他类型则没有区别，可以放心使用。 无符号整数： unsigned 修饰 有符号版本 无符号版本 char unsigned char short unsigned short int unsigned int long unsigned long long long unsigned long long 无符号版本的类型不能表示负数，但是他在正数的表达范围更大。 此外，有的教材采用不同的写法，比如： long int 和 unsigned long 等价 unsigned long long int 和 unsigned long long 等价 有符号整数： signed 修饰 有符号版本 无符号版本 signed char unsigned char signed short unsigned short signed int unsigned int signed long unsigned