企业官网建设流程全解析

简介：Manning 出版社2021年推出的《Parallel and High Performance Computing》原版PDF，面向具备一定编程基础、希望系统掌握并行与高性能计算的中高级开发者与科研人员，围绕CPU与GPU并行编程解决性能瓶颈与可扩展性问题。全包仅含1个PDF文件，大小约35.83MB，目录从并行计算导论、CPU并行主力两部分展开，覆盖并行化规划、性能上限与性能剖析、数据设计与性能模型、并行算法与模式，并深入讲解向量化、OpenMP、MPI等CPU并行技术及GPU相关实践。已有692人学习，适合作为课程教材或工程参考。读者可借助章节脉络建立从串行优化到多核、异构加速的知识框架，理解性能分析工具的使用思路、数据布局对访存与扩展性的影响，以及常见并行模式的适用边界，为科学计算与工程加速项目提供可落地的设计依据与调优方向，并避开常见的并行化误区。

1. 从 0.8% 到 99.2%：并行计算真正难的不是把循环改成并行

「串行 0.8%，并行 99.2%」——这份 2021 年出版的《并行与高性能计算》专著把这个比例印在封面上。它不是劝人别写串行代码，而是说：一段真实的高性能计算程序，纯计算逻辑往往只占极小一块，剩下九成以上的时间都消耗在与并行绑定的开销上——数据怎么摆进缓存、线程怎么同步、GPU 怎么被喂饱。很多人第一次把 CPU 上的循环改成并行版本，只快不到两倍，就断定并行不过如此。卡住加速比的从来不是那几个并行循环，而是并行化之后才暴露出来的访存模式、数据布局和通信成本。这份材料把内容拆成四块：并行计算导论、CPU 并行（向量化、OpenMP、MPI）、GPU 加速（架构、编程模型、指令制导、原生语言、性能分析）以及运行环境（线程亲和、批处理调度、并行文件操作）。下面按「上限在哪 → 数据怎么摆 → 机制怎么落地 → 哪里会翻车 → 怎么取舍」的顺序，把这几层拆开。

2. 加速比的物理上限：串行比例、机器平衡点和 Roofline 三把尺子

在动手改代码之前，有三组数字必须先算出来。算不出来，后面所有优化都是玄学：你无法判断快了两倍是接近上限还是刚摸到地板，也无法判断该加核、该换布局、还是该把整段搬到 GPU 上。这一章把这三把尺子按「先看理论上限，再看硬件脾气，最后看具体核函数落点」的顺序摆出来。

2.1 加速比上限：串行比例如何把 1024 个核压成 91 倍

最朴素的加速比模型只有一行公式：设可并行部分占比为 p，处理器数为 N，则加速比上限是

S(N) = 1 / ((1 - p) + p / N)

p = 0.95 时，16 核的极限是 9.14 倍，1024 核也只有 19.6 倍。p = 0.99 时，1024 核才勉强到 91 倍。这个结果让很多人不舒服，但它的用途不是唱衰，而是排序：它告诉你优化优先级应该是「先砍串行部分」，而不是「先加线程数」。

# 加速比上限：p 是可并行比例，n 是处理器数 def speedup(p, n): return 1.0 / ((1.0 - p) + p / n) for p in (0.90, 0.95, 0.99, 0.999): row = [f"{speedup(p, n):6.2f}" for n in (1, 8, 64, 1024)] print(f"p={p:<6}", " ".join(row)) # 反解：想在 n 核上拿到 target 倍，串行比例必须低于多少 def max_serial_fraction(target, n): # S = 1 / (s + (1-s)/n) => s = (n/S - 1) / (n - 1) return (n / target - 1.0) / (n - 1.0) print("1024 核要 100 倍，串行比例上限 =", round(max_serial_fraction(100, 1024), 6))

p是理想可并行比例，不含并行开销，实际值永远比实测好看，所以它是上限而非预测；n填物理核数，超线程下要打折，因为两个逻辑核共享一套执行单元，浮点吞吐并不会翻倍。反解函数的输出更有指导意义：想在 1024 核上拿到 100 倍，串行比例必须压到 0.9% 以内。这意味着一个只占 3% 的串行初始化和收尾，就足以让你的大规模作业永远卡在三十几倍。实践中的对策只有两条：把串行段本身并行化（比如并行读文件、并行建索引），或者让问题规模随核数一起长——后者就是强扩展与弱扩展的分野，弱扩展下加速比的分母变了，那条渐近线也就不再是天花板。

2.2 机器平衡点：算术强度决定该优化算力还是带宽

第一个尺子只管「串行多少」，不管「硬件擅长什么」。第二个尺子把代码和硬件对上：算术强度 I = 浮点运算次数 / 访存字节数，机器平衡点 B = 峰值浮点性能 / 峰值带宽。I > B 说明计算受限，加算力有用；I < B 说明访存受限，再怎么调数学公式都没用，得改数据流动。

PEAK_GFLOPS = 512.0 # 单节点双精度峰值 = 核数 × 频率 × 每周期 FMA 数 × 2 PEAK_GBPS = 100.0 # 必须是 STREAM 实测带宽，不是厂商标称值 balance = PEAK_GFLOPS / PEAK_GBPS # 单位 FLOP/Byte print(f"机器平衡点 = {balance:.2f} FLOP/Byte") kernels = { "stream triad": 2 / 24, # 每元素 2 FLOP，读写 3 个 double "7 点 stencil": 7 / 64, # 每点约 7 FLOP，读写 8 个 double "dense GEMM 256^3": 2 * 256**3 / (3 * 256**2 * 8), } for name, ai in kernels.items(): print(f"{name:20s} I={ai:7.3f} {'计算受限' if ai > balance else '访存受限'}")

这里最容易踩的坑是拿标称带宽当分母。厂商标称的峰值带宽，实际跑 STREAM 通常只能到六七成，用标称值算出来的平衡点偏低，会让人误以为很多核是计算受限，结果优化方向整条跑偏。PEAK_GFLOPS也要注意：只统计 FMA 单元真正能发出来的双精度浮点，不算理论指令发射数。按上面这组参数，平衡点在 5.12，而 stream triad 的算术强度只有 0.083——差六十倍。这就是为什么带宽测试程序永远跑不满浮点峰值，也是为什么在访存受限的核上做代数化简（比如把a*b+a*c改成a*(b+c)）几乎不会带来任何提速。

2.3 Roofline 拐点：同一段核函数为什么在 GPU 上换了瓶颈

把前两个尺子画在同一张双对数图上就是 Roofline：水平线是峰值浮点，斜线是「带宽 × 算术强度」，交点叫拐点，坐标正好是机器平衡点。拐点左侧受带宽限制，右侧受算力限制。

def roofline(peak_gflops, peak_gbps): knee = peak_gflops / peak_gbps # 拐点处的算术强度 def ceiling(ai): return min(peak_gflops, peak_gbps * ai) return knee, ceiling cpu_knee, cpu_ceiling = roofline(512, 100) # 拐点 5.12 gpu_knee, gpu_ceiling = roofline(7000, 900) # 拐点 7.78 for ai in (0.083, 0.2, 1.0, 5.0, 20.0): c, g = cpu_ceiling(ai), gpu_ceiling(ai) print(f"I={ai:6.3f} CPU={c:8.1f} GPU={g:8.1f} GFLOPS 倍数={g/c:5.1f}x")

输出里藏着一个很反直觉的结论：算术强度 0.083 时，GPU 相对 CPU 只有约 9 倍提升，恰好等于两者带宽之比；算术强度到 20 时，倍数才升到 13.7 倍，等于算力之比。也就是说，把 stream triad 这类低强度核搬到 GPU 上，你拿到的只是带宽红利，剩下的算力全在空转。这份材料在 GPU 部分专门用 mixbench 一类的工具按算术强度扫描硬件，目的就是让开发者在写第一行 kernel 之前就知道：这个 workload 在这块卡上到底能跑到峰值的百分之几。拐点位置还解释了另一件事——GPU 的峰值浮点比 CPU 高一个数量级，但带宽只高几倍，所以拐点右移，一大批在 CPU 上算「计算受限」的核，搬到 GPU 上直接变成「访存受限」。同一个 kernel，两套优化思路。

3. 数据布局：为什么换个数组顺序能快几倍

算完上限，接下来是收益最大也最容易被忽视的一层：数据怎么摆。同一份数据、同一套算法，只是换了遍历顺序或字段排列，实测差三到十倍是常见的事。这一层没有公式可套，但有明确的失效机制可以逐条排查。

3.1 三 C 缓存缺失：强制、容量、冲突各自的解法

缓存缺失分三类，解法完全不同，混为一谈就会白费力气。强制缺失（compulsory）是数据第一次被访问，无法避免，只能靠减少总访问量。容量缺失（capacity）是工作集超过缓存容量，解法是分块——把大矩阵切成能塞进 L2 的小块，块内反复复用。冲突缺失（conflict）最隐蔽：工作集明明没超容量，但因为组相联映射的规律，几个热点地址反复映射到同一组，互相踢出。典型触发场景就是按列遍历行主序数组。

#define N 4096 static double A[N][N]; /* 行优先：内层沿最后一维走，步长 8 字节， 一个 64B 缓存行装 8 个 double，预取器全程有效 */ double sum_rows(void) { double s = 0.0; for (int i = 0; i < N; i++) for (int j = 0; j < N; j++) s += A[i][j]; return s; } /* 列优先：内层跨行，步长 N*8 = 32KB， 每个缓存行只用 1 个 double，浪费 7/8 的带宽 */ double sum_cols(void) { double s = 0.0; for (int j = 0; j < N; j++) for (int i = 0; i < N; i++) s += A[i][j]; return s; }

N = 4096时整个数组 128MB，远超末级缓存；列遍历的步长 32KB 又正好落在页和缓存组的整数倍上，冲突缺失和 TLB 缺失会叠加发生。修法有三条：改遍历顺序（免费）、分块（把 128MB 的问题切成 256×256 的块，块内两种顺序都行）、或者给数组每行末尾补几个填充元素打破对齐规律。第三条是血泪经验——补 8 个 double 常常能让某些 stencil 核快 20%，原因就是错开了缓存组映射。

提示：判断到底是容量还是冲突，最直接的办法是把问题规模缩小一半再测。耗时按比例下降是容量问题，几乎不变就是冲突问题。

3.2 AoS 与 SoA：字段挨着还是粒子挨着，决定了能不能向量化

粒子、网格点这类「结构体数组」是并行代码里最常见的组织方式，而它的字段排列直接决定编译器敢不敢向量化。AoS 把一个实体的所有字段放在一起，SoA 把所有实体的同一字段放在一起，AoSoA 则是折中：每若干个实体一组，组内 AoS、组间 SoA。

/* AoS：一个粒子的 x,y,z,mass 连续存放 */ struct particle_aos { float x, y, z, mass; }; struct particle_aos aos[N]; /* SoA：所有粒子的同一字段连续存放，天然适合 SIMD 加载 */ struct particles_soa { float x[N], y[N], z[N], mass[N]; }; /* AoSoA：8 个粒子一组，组内 AoS，组间 SoA */ #define LANES 8 /* 与向量寄存器宽度对齐：256 位下 8 个 float */ struct particles_aosoa { struct { float x, y, z, mass; } block[N / LANES][LANES]; };

只更新 x 坐标时，AoS 每次要跨 16 字节取 4 字节，一条 64B 缓存行只用到 1/4，向量化加载还要做跨步 gather；SoA 下x[i..i+7]是一条连续的 32B 加载，编译器直接生成一条 SIMD 指令。但要同时用 x、y、z 算距离时，SoA 会发出三条指向三个不同缓存行的加载，而 AoSoA 在一个块里全拿到。LANES不是随便定的：它要匹配目标硬件的向量寄存器宽度，256 位下是 8 个单精度，512 位下是 16 个，填错就等于白白浪费一半通道。实际工程里我一般先按 SoA 写，等发现某段核反复同时访问多字段、且 profiler 显示 L1 命中率掉下来，再局部改成 AoSoA。

3.3 CSR 稀疏存储：为什么 SpMV 永远吃不满浮点峰值

稀疏矩阵是科学计算的主力，稠密存储会让内存直接爆掉：一百万阶的矩阵，稠密存是 8TB，而实际非零元可能只有千万级。CSR 按行压缩，三个数组搞定：val存非零值、col_idx存列号、row_ptr标记每行在val里的起止位置，长度是 n+1。

/* CSR 稀疏矩阵向量乘：y = A * x */ void spmv_csr(int n, const int *row_ptr, const int *col_idx, const double *val, const double *x, double *y) { for (int i = 0; i < n; i++) { double acc = 0.0; for (int k = row_ptr[i]; k < row_ptr[i + 1]; k++) acc += val[k] * x[col_idx[k]]; /* 间接寻址：gather，无法向量化 */ y[i] = acc; } }

row_ptr[i]到row_ptr[i+1]是第 i 行的非零区间，col_idx[k]指出这一项乘 x 的哪个分量。问题出在x[col_idx[k]]：地址要等运行期才知道，编译器无法生成连续加载，只能逐个 gather；而且每行的长度不定，向量化还会被边界打散。按算术强度算，SpMV 每个非零元做 2 次浮点、读 12 字节（值 8B、列号 4B，x 的访问算随机），强度约 0.17，远低于 5.12 的机器平衡点——它永远访存受限。所以 SpMV 的优化方向从来不是提浮点吞吐，而是减少索引开销和提升访存局部性：块压缩格式把行内相邻非零元打包成固定宽度块，用稠密小块替换细粒度间接寻址，让向量化重新变得可能。这份材料在数据设计一章里给出的几个简单性能模型，核心用途就是让你在选格式之前先估出「这个格式大概能跑到峰值几分之一」。

4. 并行机制：从 SIMD 到 GPU 线程，同一套抽象怎么落地

上限和数据布局是「纸上」的部分，接下来是真正下发到硬件的那一层。CPU 上有三层并行可以叠：单核内的 SIMD、核间的线程、节点间的进程。GPU 上则是另一套线程层次加主机设备两段式执行。它们看着差别很大，本质都在解决同一件事——把一个数据并行的问题切成互相独立的执行单元，同时把同步和通信压到最低。

4.1 向量化：编译器在哪些条件下直接放弃

SIMD 向量化是性价比最高的一层：不用改算法、不用加线程，只要让编译器敢做，往往就有 2 到 8 倍。但它极其依赖几个前提，缺一个就退化成标量循环。

/* 编译器不敢向量化：a、b、c 可能指向重叠内存， 写 a[i] 有可能改变后面要读的 b[i+1] */ void add_maybe_alias(double *a, const double *b, const double *c, int n) { for (int i = 0; i < n; i++) a[i] = b[i] + c[i]; } /* restrict 是程序员对编译器的承诺：三块内存互不重叠 */ void add_no_alias(double *restrict a, const double *restrict b, const double *restrict c, int n) { for (int i = 0; i < n; i++) a[i] = b[i] + c[i]; }

restrict是 C99 关键字，语义是「在本函数作用域内，这块内存只通过这个指针访问」。它是承诺而非保证——真传了重叠指针属于未定义行为，后果自负。除了别名，还有几种常见劝退因素：循环体内有函数调用（除非内联）、有数据依赖（a[i] += a[i-1]）、有难以向量化的条件分支、访存不连续（结构体数组或间接索引）。实践中有效的做法是打开编译器的向量化报告（-O3 -march=native -fopt-info-vec这一类），逐条看它给出的「未向量化原因」，再针对性改写成临时数组、拆分循环或加编译制导。改完一定要重新看报告并且验证数值结果——向量化改变的是求和顺序，浮点结果会有末位差异，这不是 bug，但得有心理准备。

4.2 OpenMP 的作用域与伪共享：shared 变量是最常见的翻车点

线程层的坑几乎全部集中在变量作用域上。OpenMP 的默认规则是：并行区域外声明的变量默认 shared，循环索引默认 private。这条规则记不住，就会写出「结果每次不一样」的代码。

/* 错误：sum 是 shared，多个线程同时做 += 会丢更新 */ double sum = 0.0; #pragma omp parallel for for (int i = 0; i < n; i++) sum += a[i]; /* 正确：reduction 让每个线程持有私有副本，结束时合并 */ double sum_ok = 0.0; #pragma omp parallel for reduction(+:sum_ok) for (int i = 0; i < n; i++) sum_ok += a[i];

reduction(+:sum_ok)的语义是每个线程创建一份初值为 0 的私有副本，循环结束后按线程号顺序归并。注意「按线程号顺序」不等于「按原始顺序」——归并顺序取决于线程数，所以同一个程序用 4 线程和 8 线程跑，浮点结果末位可能不同。这在回归测试里必须容忍，或者改用确定性的成对归约。

伪共享是第二条高频陷阱，它不产生错误结果，只吞性能，所以更难发现：

/* counters 的 4 个 int 落在同一个 64B 缓存行， 4 个线程各写各的，硬件仍要来回搬这一整行 */ int counters[4]; #pragma omp parallel for for (int t = 0; t < 4; t++) for (int i = t; i < n; i += 4) counters[t]++; /* 每个计数器独占一行，代价是内存放大 */ struct padded_counter { int v; char pad[60]; } cs[4];

pad[60]让每个结构体正好 64 字节，也就是一个缓存行的宽度。代价是内存占用放大十几倍，所以只对真正的高频写入点用。定位伪共享靠猜很难，得用线程竞争检查

本文还有配套的精品资源，点击获取