简介针对并行计算课程学习与实验复现需求这份郑州大学计算机与人工智能学院实验报告适合正在学习并行计算、准备课程实验或希望补齐性能分析思路的学生参考作者在该课程中取得90分以上成绩。内容围绕任务分解、负载均衡、通信同步等基础概念展开并覆盖共享内存与分布式内存模型、矩阵乘法/FFT/排序等并行算法设计以及并行图像绘制、像素级加速、Gprof与Intel VTune性能剖析、OpenMP/MPI/CUDA/OpenCL实验环境等实践环节同时涉及性能瓶颈识别、并行度评估与缓存效率分析末尾还包含实验总结与后续研究方向展望。资源以zip压缩包分发约37.69MB文件总数显示为0、类型明细暂无数据具体目录需下载后查看。已有701人学习可作为理解并行计算核心概念、对照实验过程、复现代码与优化思路的课程参考资料。1. 并行计算实验的知识地图四条主线一次串起来并行计算这门课的实验报告很多人卡在同一个地方代码能跑出结果但不知道该测什么、该画什么图、图上那条线为什么死活到不了理想值。这份在课程里拿到 90 的实验报告真正值钱的不是几段能跑的代码而是它背后那张地图——性能指标加速比、效率、扩展性是标尺Amdahl 与 Gustafson 两条定律是天花板MPI、OpenMP、CUDA 三套编程模型是工具矩阵乘、归约、前缀和、排序是练手靶子最后用绘图把结论落在坐标轴上。四条主线咬合起来实验报告才不是流水账而是一份能自证的性能分析。这份笔记就按这张图往下拆适合正在跟实验、准备验收答辩或期末复习的人。2. 性能三件套加速比、效率与两条定律怎么算才不作假性能部分是整份实验报告的骨架。代码写得再花哨如果加速比算错口径、基线选得不对整份报告的结论都会站不住。这一章把三个核心量加速比、并行效率、扩展性和两条定律Amdahl、Gustafson拆开讲清楚重点放在“口径”和“适用边界”上因为这两处正是评分时最容易被追问的地方。2.1 加速比与并行效率公式背后的三个口径加速比的定义看起来只有一行S(p) T₁ / TₚT₁ 是串行执行时间Tₚ 是使用 p 个处理单元后的时间。问题出在 T₁ 到底取哪一个是最优的串行算法还是“把并行程序改成单进程跑一遍”这两种口径算出来的加速比可能差一倍以上。实验报告里必须写明用的是哪一种否则后面的曲线没法解释。常见做法是三选一并在报告中固定下来单进程并行版最保守能反映并行框架的额外开销比如 MPI 单进程仍有 Init/Finalize 成本、纯串行版最能体现“并行带来的净收益”、库函数基线比如矩阵乘直接调 BLAS 单线程用来检验自研代码是否已经输在起跑线上。并行效率则是把加速比按核数摊平E(p) S(p) / p理想情况下 E 1实际几乎永远小于 1。效率下降的四个来源要在报告里逐一对应通信开销、同步等待、串行段初始化、IO、结果汇总、负载不均。把这四条写进“结果分析”比单纯说一句“效率随核数下降”要有说服力得多。进程/线程数 p时间 Tₚ(s)加速比 S(p)效率 E(p)主要瓶颈112.401.001.00串行基线26.551.890.95通信占比小43.483.560.89同步等待82.105.900.74负载不均 内存带宽161.627.650.48串行段占比放大这张表本身就是报告里最有价值的一页它同时给出了原始数据、推导量和归因。表里的数字是示意量级真实实验要以自己机器上跑出来的为准但结构可以直接照搬。计算这些量的脚本建议单独放一个文件避免手算出错# perf_metrics.py从原始计时数据生成加速比/效率表 def speedup(t1, tp): t1: 串行基线耗时tp: p 个单元下的耗时 return t1 / tp def efficiency(t1, tp, p): 并行效率 加速比 / 处理单元数理想值为 1.0 return speedup(t1, tp) / p raw [(1, 12.40), (2, 6.55), (4, 3.48), (8, 2.10), (16, 1.62)] t1 raw[0][1] # 以单进程实测值为基线口径写进报告 for p, tp in raw: print(fp{p:2} S{speedup(t1, tp):.2f} E{efficiency(t1, tp, p):.2f})参数上要注意t1必须是同一份代码、同一组编译选项下的测量值不能串行版用-O0、并行版用-O3那样加速比里混进了编译器优化的贡献属于典型的“加速比造假”。2.2 Amdahl 与 Gustafson两个定律分别管什么Amdahl 定律回答的是“问题规模固定时加核能带来多少收益”S(p) 1 / (s (1 - s) / p)其中 s 是程序中无法并行的比例。当 p 趋于无穷加速比上界收敛到 1/s。这个结论常被误读成“并行没前途”其实它的前提是问题规模不变。举个数s 5%p 16S 1 / (0.05 0.95/16) ≈ 9.14距离理论 16 核差了一大截而不管加到多少核天花板都停在 20。Gustafson 定律换了个前提核数增加时问题规模同步变大测的是“同样时间内能算多大规模”S(p) s p(1 - s)同样 s 5%、p 16得到 15.25几乎线性。这不是说 Gustafson 更乐观而是两者度量的东西不同。维度AmdahlGustafson固定量问题规模执行时间加速比含义同一任务更快完成同样时间算更大任务上界1/s随 p 线性增长对应实验强扩展strong scaling弱扩展weak scaling报告里怎么用解释曲线为何在高核数处压平解释大规模型号为仍能保持高效率写报告时最容易翻车的地方是只算 Amdahl 上界却拿它去解释弱扩展实验的曲线。两条定律各自对应一种实验设计混用就是逻辑错误。2.3 强扩展与弱扩展实验该测哪一条曲线强扩展固定问题规模 n只增加 p观察时间如何下降。理想曲线是 Tₚ T₁/p实际会在某个核数之后压平压平点就是这套硬件和这个算法的“有效并行区间”。弱扩展固定每个处理单元上的工作量即 n 随 p 等比放大观察时间是否基本不变衡量的是算法和实现的可扩展上限。实验设计上建议两条都做代价不大但结论完整实验类型固定量自变量观测量期望曲线强扩展矩阵规模 n、迭代次数p 1,2,4,8,16时间、加速比、效率加速比上升后趋平弱扩展每核负载 n/pp 同上时间、scaled speedup时间近似水平线在报告里画图时横轴用 p纵轴用加速比并叠加一条 y x 的理想线作为参照读者一眼就能看出实际曲线偏离理想线多少。弱扩展那张图的纵轴换成时间更直观因为理想情况就是一条水平线偏离多少一目了然。还有一个常被忽略的细节p 的取值应该覆盖到物理核数之外一点点比如 8 核机器测到 16这样才能观察到超订oversubscription导致的性能回落而这个回落本身就是很好的分析素材。3. 三大编程模型MPI、OpenMP、CUDA 的边界与重点同一道并行题用 MPI 写和用 OpenMP 写代码结构、开销来源、甚至“什么算一个处理单元”的定义都不同。这一章按“地址空间”这条主线把三套模型分开MPI 是独立内存的进程间通信OpenMP 是共享内存的线程级并行CUDA 是异构设备上的海量线程。搞清边界才知道什么场景该选谁也才知道实验里的开销到底该归到哪一类。3.1 MPI进程级分布式的通信骨架MPI 采用 SPMD 模型所有进程跑同一份程序靠 rank 区分身份。程序的固定骨架是 Init → 取 rank/size → 计算与通信 → Finalize缺一不可。#include mpi.h #include stdio.h int main(int argc, char **argv) { int rank, size; MPI_Init(argc, argv); MPI_Comm_rank(MPI_COMM_WORLD, rank); // 当前进程编号 0..size-1 MPI_Comm_size(MPI_COMM_WORLD, size); // 进程总数 double t0 MPI_Wtime(); // 计时统一用 MPI_Wtime double local 1.0 / (rank 1); // 各进程的局部贡献 double total 0.0; /* 集合归约所有进程的 local 求和后写入 root(0) 的 total */ MPI_Reduce(local, total, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD); double t1 MPI_Wtime(); if (rank 0) // 只让 0 号进程做输出避免重复打印 printf(p%d time%.6f sum%.6f\n, size, t1 - t0, total); MPI_Finalize(); return 0; }编译用mpicc -O3 -o reduce reduce.c运行用mpirun -np 8 ./reduce。参数上要盯住几处MPI_Reduce的root决定结果落在谁手里MPI_DOUBLE必须和变量类型严格一致长度参数1表示一个元素而不是字节数。这几处类型不匹配在运行时不报错、结果却是垃圾值调试起来非常折磨。重点难点集中在通信模式上。最典型的问题是死锁所有进程都先MPI_Send再MPI_Recv而标准 Send 在小缓冲下可能直接阻塞直到对方接收于是所有进程互相等待。解决办法是把收发合并成MPI_Sendrecv或者用非阻塞的MPI_Isend/MPI_Irecv加MPI_Waitall。另一个坑是边界处理按行分块时如果行数不能被进程数整除最后几个进程要处理n % size这个余数块漏掉就会少算数据。集合通信的语义差异也要背下来Bcast一对多、Scatter把不同数据分给不同进程、Gather反向收集、Allreduce是 Reduce 之后把结果再广播给所有人。写报告时把每处通信的作用和数据量标出来通信开销才有依据。3.2 OpenMP共享内存的指令式并行OpenMP 是编译制导模型靠#pragma把一个循环或代码块标记成并行区线程由运行时库管理进程内共享地址空间。好处是改造串行代码的成本极低坏处是数据竞争不会在编译期提示你。#include omp.h #include stdio.h int main(void) { const int N 100000000; double sum 0.0; double t0 omp_get_wtime(); /* reduction 让每个线程持有私有副本退出并行区时自动合并 */ #pragma omp parallel for reduction(:sum) schedule(static) for (int i 0; i N; i) { sum 1.0 / (i 1); // 无跨迭代依赖可安全并行 } double t1 omp_get_wtime(); printf(threads%d time%.6f sum%.6f\n, omp_get_max_threads(), t1 - t0, sum); return 0; }编译命令gcc -O3 -fopenmp sum.c -o sum注意-fopenmp同时影响编译和链接漏掉就会把 pragma 当注释忽略程序静静地串行跑完加速比恒等于 1——这个坑极其常见甚至在报告里表现为“并行无效”的错误结论。关键点在数据环境。默认情况下并行区外的变量是共享的只有在private/firstprivate/reduction子句里声明的才变成线程私有。循环变量i自动私有但如果你在循环里累加到一个裸共享变量上就会产生数据竞争结果每次跑都不一样。这类“看起来对、结果随机”的 bug 是血泪经验的重灾区。循环能不能并行判断标准只有一条第 i 次迭代是否依赖第 i-1 次的结果。像a[i] a[i-1] b[i]这种递推直接加 pragma 会得到错误结果需要改写成分段并行或前缀和一类算法。调度策略也要选static适合每次迭代耗时均匀的循环dynamic和guided适合迭代耗时不均的场景后者能改善负载均衡但会引入调度开销值得在报告里做一组对比。3.3 CUDA从线程层次到内存层次CUDA 的核心是三层映射grid 划分成 blockblock 划分成 thread硬件以 32 个线程组成的 warp 为调度单位。写 kernel 时脑子里要同时有“逻辑线程坐标”和“硬件执行单元”两套图。/* 块内树形归约每个 block 求一段的和写回 out[blockIdx.x] */ __global__ void reduce_sum(const float *in, float *out, int n) { extern __shared__ float sdata[]; // 动态共享内存大小由启动时指定 int tid threadIdx.x; int idx blockIdx.x * blockDim.x threadIdx.x; sdata[tid] (idx n) ? in[idx] : 0.0f; // 越界位置补 0保证归约正确 __syncthreads(); // 整块数据写完再开始归约 for (int s blockDim.x / 2; s 0; s 1) { if (tid s) sdata[tid] sdata[tid s]; // 步长折半深度 log2(blockDim) __syncthreads(); // 每轮必须同步漏掉就是数据竞争 } if (tid 0) out[blockIdx.x] sdata[0]; // 每块输出一个部分和 }启动配置和计时同样有讲究int block 256; int grid (n block - 1) / block; // 向上取整最后一块可能不满 size_t shmem block * sizeof(float); cudaEvent_t start, stop; cudaEventCreate(start); cudaEventCreate(stop); cudaEventRecord(start); reduce_sumgrid, block, shmem(d_in, d_out, n); cudaEventRecord(stop); cudaEventSynchronize(stop); // kernel 异步执行必须显式等待 float ms 0.0f; cudaEventElapsedTime(ms, start, stop);三层内存的分工必须清楚global memory 容量大但延迟高shared memory 带宽高但每块只有几十 KBregister 最快但数量有限。归约之所以比朴素写法快一个数量级靠的就是把重复访问搬到 shared memory 里。两个高频错误漏掉__syncthreads()导致结果时对时错shared memory 数组按 32 取整对齐不当引发 bank conflict同一个 warp 内多个线程访问同一 bank 的不同地址访问会被串行化。把sdata[tid]改成sdata[tid tid/32]这类填充写法可以缓解代价是多占一点空间。3.4 模型选型与混合编程三套模型的边界可以用一张表固定下来写报告时“为什么选这个模型”就有依据了维度MPIOpenMPCUDA并行粒度进程跨节点线程单节点内线程设备内海量地址空间独立需显式通信共享需防竞争主机与设备分离需拷贝典型开销来源网络延迟、数据打包同步、伪共享主机设备传输、启动延迟适合的问题大规模分布、多机规则循环、单机多核高算术强度、数据并行上手成本中通信设计难低改造成本低高内存管理复杂实际系统里三者经常叠着用MPI 负责跨节点分发节点内用 OpenMP 起多线程加速卡上再挂 CUDA kernel。实验报告如果只做单机实验至少要说明“如果扩展到多节点当前设计需要改哪一层”。这句话能体现你理解模型的边界而不是只会调 API。工具链也值得写进环境说明CPU 侧用编译器的-O3 -marchnative性能剖析靠perf或厂商提供的性能分析软件/插件看热点函数GPU 侧用nsys看时间线、ncu看访存效率。深度学习框架能把大模型训练跑起来底层依赖的正是这些并行模型和通信库所以这套工具链的认知不只对课程实验有用。4. 经典并行算法实验矩阵乘、归约、前缀和与排序实验题目的选择不是随意的每个经典问题对应一种并行模式矩阵乘练数据划分和分块归约练树形结构前缀和练扫描scan这种更复杂的信息传播模式排序练比较交换网络和负载均衡。这一章按“并行模式 → 实现要点 → 实验观察什么”的顺序过一遍每个问题都给出可复现的细节。4.1 矩阵乘法分块、数据划分与算术强度朴素三重循环的复杂度是 O(n³)计算量 2n³ 次浮点运算读入 3n² 个元素算术强度 O(n)属于典型的计算密集型最适合并行化。但直接并行化会遇到访存瓶颈如果按 i 外层循环并行、内层按 j-k 顺序访问B 矩阵是按列访问的缓存命中率极低。第一步优化与并行无关是循环顺序和分块把最内层循环换成对 k 的连续访问让 B 的访问变成行优先连续再把矩阵切成 b×b 的小块b 取 16 到 64让三个块同时塞进 L1/L2块内做小矩阵乘。这一步在单线程上通常就有数倍提升很多实验报告的“加速比”其实就是被这一步撑起来的报告中必须把“串行优化后的基线”和“原始三重循环”分开列否则加速比会虚高。/* 分块矩阵乘核心片段C A * B均为 row-major n×n */ for (int ii 0; ii n; ii B) { for (int jj 0; jj n; jj B) { for (int kk 0; kk n; kk B) { /* 三个块同时在缓存中块内仍是三重循环 */ for (int i ii; i ii B i n; i) { for (int k kk; k kk B k n; k) { double a A[i * n k]; // A 的元素复用 B 次 for (int j jj; j jj B j n; j) C[i * n j] a * B[k * n j]; // 连续访存 } } } } }块大小B是唯一需要调的参数太小则缓存复用不足太大则三个块放不下、互相驱逐。经验上让3 * B * B * sizeof(double)接近 L2 容量的一半比较稳可以在报告里做一组 B 8/16/32/64 的对比曲线这本身就是很好的实验内容。并行化的方式有三条路各有取舍划分方式通信量负载均衡适用模型按行块划分 A广播 B中等广播 n²好行数均分MPI二维块划分棋盘格低行列各广播一次好MPI如 Cannon 算法按输出元素并行无好OpenMP / CUDAMPI 版本里最直观的是行块划分0 号进程读入 A、B用MPI_Bcast把 B 广播给所有进程再用MPI_Scatter或MPI_Send循环把 A 的行块分发下去各进程算完自己的 C 行块后MPI_Gather回 0 号。注意 scatter 的发送缓冲区、接收缓冲区、count 参数三者的单位要一致且 n 不能被进程数整除时要单独处理余数这是最常出现的数组越界来源。4.2 归约与前缀和树形结构的两种写法归约求和、求最值、求乘积是最基础的并行原语几乎所有集合通信底层都是它。串行归约是 O(n) 的链式依赖并行的思路是把链改成树第一轮相邻两个元素相加第二轮间隔 2 个相加以此类推深度降到 log₂n。/* 单线程模拟树形归约的步长变化理解并行版本的执行顺序 */ double tree_reduce(double *a, int n) { for (int stride 1; stride n; stride 1) { // 步长 1,2,4,8... for (int i 0; i stride n; i stride 1) { a[i] a[i stride]; // 相邻块两两合并 } } return a[0]; // 累加到首元素 }这段代码帮助理解归约的合并顺序实际在 OpenMP 里用reduction子句、在 MPI 里用MPI_Reduce、在 CUDA 里用共享内存树形归约即可不需要手写。要提醒的是浮点加法不满足结合律不同的合并顺序会带来末位差异实验报告里如果发现并行结果和串行结果在小数点后若干位不同那不是 bug而是浮点累加顺序变化的正常现象解释清楚反而是加分项。前缀和scan比归约难一档因为它要求每个位置都拿到前缀结果。两种经典算法差别很大算法工作量深度特点Hillis-SteeleO(n log n)O(log n)实现简单读取量大BlellochO(n)O(2 log n)先上扫再下扫工作量最优但常数大Hillis-Steele 的写法直观第 d 轮让a[i] a[i - 2^d]每轮并行执行全部元素深度 log n代价是总工作量比串行多 log n 倍。Blelloch 走的是 up-sweep 加 down-sweep 两条路工作量回到 O(n)但两趟扫描让代码复杂度上升。实验里两个都实现、对比时间和正确性比只做一个更有说服力。前缀和的典型应用是并行排序里的 ranking 步骤和稀疏矩阵的行偏移计算报告里可以点一句应用背景。4.3 排序与易并行问题双调排序与蒙特卡洛并行排序的难点在于快排的划分步骤天然串行选一个 pivot把数组分成两半这个划分本身是 O(n) 的串行操作。并行化的思路一是分段并行划分每个线程处理一段再合并分段边界二是换成比较交换网络比如双调排序bitonic sort。双调排序的思想是先把序列排成“先增后减”的双调序列再用比较交换把双调序列合并成有序序列整个过程由 log²n 轮比较交换组成每一轮内部完全并行、无数据依赖非常适合 GPU。代价是总比较次数比快排多属于“用工作量换算并行度”的典型。它的实现要点是每一轮的比较伙伴索引要按位运算计算边界判断容易写错建议先用小规模 n 8 手工推演一遍每轮的下标变化再写代码。另一类是“易并行”问题比如用蒙特卡洛方法估算 π每个线程独立生成随机点、判断是否落在单位圆内最后统计比例。这类问题几乎没有通信加速比接近线性很适合作为“并行开销下限”的参照实验。有一个坑必须提随机数种子如果所有线程用同一个固定值每个线程生成的序列会完全一样统计结果偏差极大。正确做法是按线程编号或进程编号偏移种子比如seed base_seed rank * 1000 tid并在报告里说明这一点。这个细节看起来小但它是区分“跑通了”和“做对了”的分水岭。算法并行模式通信需求实验观察点矩阵乘数据划分 分块中广播/分发块大小对缓存的影响归约树形合并高每轮同步深度与线程数的关系前缀和扫描高多轮两种算法的工作量差异双调排序比较交换网络低轮内独立轮数与 n 的对数关系蒙特卡洛完全独立极低随机数种子分离是否正确4.4 通信开销估算从理论到实测的差距所有并行实验最后都会撞上同一堵墙加速比上不去而理论上明明应该可以。原因通常藏在通信开销里。一个够用的简化模型是T(p) T_compute / p α · m β · D其中 α 是每次通信的启动延迟微秒级与消息大小无关β 是单位数据的传输时间由带宽决定m 是消息条数D 是数据量。这个模型解释了两个常见现象消息条数多但每条都很小时α · m 占主导所以“少发多次”不如“合并成一次大消息”数据量大时 β · D 占主导这时要看带宽而不是延迟。测量方法很简单做一个纯通信微基准固定 p让进程之间来回发送不同大小的消息1B、1KB、1MB、16MB记录往返时间画出时间随消息大小的曲线斜率的倒数就是有效带宽截距就是启动延迟。这条曲线放进报告前面所有“通信开销大”的判断就都有了实测支撑而不是一句空话。另一个必须解释的现象是问题规模太小时加速比可能小于 1也就是“越并行越慢”。这不是实验失败而是并行开销进程启动、数据分发、结果汇总超过了计算本身的收益。把 n 从小到大扫一遍找到加速比开始大于 1 的拐点这个拐点就是这套实现的最小有效规模写进报告比任何理论分析都直观。5. 易错点盘点计时、伪共享与加速比造假做完整套实验再回头看真正让人翻车的往往不是算法想不出来而是一些“看起来没问题”的细节。这一章把最容易漏、最容易错的地方按两类整理一类是测量口径问题一类是并发正确性和硬件相关问题。每条都按“易漏点 → 为什么漏 → 怎么补”写对着自查一遍能省掉大量返工。5.1 计时与基线三个最常见的口径错误易漏点一把初始化和 IO 算进了并行时间。为什么漏代码里计时器随手加在main开头读文件、分配内存、进程启动全被算进去了而这些恰恰是串行段。怎么补计时只包住核心计算循环MPI 版本在MPI_Barrier之后取MPI_Wtime()CUDA 版本用cudaEventRecord包住 kernel 并用cudaEventSynchronize等待OpenMP 用omp_get_wtime()放在并行区前后。同时确认“计时点前后的变量没有被编译器优化掉”必要时把结果打印出来或加volatile。易漏点二串行基线和并行版本编译选项不一致。为什么漏调试时串行版用-O0方便断点并行版顺手写了-O3加速比里混进了编译器优化的功劳数字漂亮但不成立。怎么补所有版本统一用-O3或统一-O2并在报告的环境说明里明确写出编译命令。更进一步跑一次“并行版单进程”作为对照组它能反映框架本身的固定开销。易漏点三只测一次且包含首次运行的冷启动。为什么漏首次运行有页表建立、缓存预热、动态库加载、GPU 上下文初始化等一次性成本单次测量波动可能超过 20%。怎么补先跑若干次 warm-up 丢弃再重复测 5 到 10 次取中位数比平均值更抗异常值报告里给出中位数和波动范围。这个习惯一旦养成后面所有曲线都会稳很多。提示中位数和平均值的差别在小样本下很明显报告里写清用了哪一个评审时不会被追问口径。5.2 并发正确性与硬件两个不报错但结果错的坑易漏点四伪共享让多线程比单线程还慢。为什么漏多个线程分别累加数组中相邻的元素这些元素落在同一条 64 字节缓存行上硬件为了保证一致性会反复让缓存行在核间失效性能断崖式下跌但程序结果完全正确所以不会引起任何警觉。怎么补每个线程的累加变量用独立数组并按缓存行填充padding 到 64 字节的整数倍或者干脆每线程先累加到局部变量、最后统一归约。判断方法是对比“相邻累加”和“填充后累加”两组时间差异通常非常明显。易漏点五超线性加速被当成成果写进结论。为什么漏p 个进程跑出大于 p 的加速比第一反应是“优化得真好”。实际上常见原因有三串行基线用了不同的算法或不同的数据规模问题规模变小后整个工作集装进了缓存单核跑的时候反而在反复换页并行算法带剪枝提前终止了搜索。怎么补出现超线性时逐条排查——基线是否同算法同规模、缓存是否解释了性能跃变、并行版本是否少做了工作。报告里如实写出原因比掩盖掉更能体现分析能力。易漏点六MPI 通信顺序与边界处理留下的隐性错误。为什么漏小规模测试时进程数正好整除、消息很小、标准 Send 恰好被缓冲一切正常换成 8 进程或不整除的规模就挂死或少算。怎么补固定用MPI_Sendrecv或非阻塞收发避免环形等待在分发数据前显式处理n % size的余数块一般让前n % size个进程多拿一行调试时先用-np 1和-np 3这种奇怪的进程数跑一遍能提前暴露大部分边界问题。把这六条对着自己的实验过一遍基本能避开绝大多数“结果对但结论错”的情况。剩下的就是耐心把每一组数据都记录原始时间而不是只记录算出来的加速比因为后期一旦发现口径有问题原始数据还能救回来。6. 复习清单从公式默写到图表复现的查漏补缺法复习这部分内容最没效率的方式是从第一页翻到最后一页。更有效的做法是按“能默写、能解释、能复现”三档自查把模糊的地方挑出来重点补。下面这份清单是我自己反复用过的按优先级排档次自查内容达标标准能默写加速比、效率、Amdahl、Gustafson 四个公式不看资料写出并说明每个符号含义能默写MPI 六个集合通信的语义差异能画出 Bcast/Scatter/Gather/Reduce 的数据流向能解释加速比上不去的四类原因每条能对应到一个实验现象能解释强扩展与弱扩展的曲线形态差异说清各自固定了什么量能解释伪共享、bank conflict、warp 发散的成因各给一个缓解办法能复现计时脚本与绘图脚本换一组数据能直接出图能复现一个 MPI 程序和一个 OpenMP 程序从零写出来并编译运行通过绘图这一步特别值得单独练。报告里的图不是“把数据丢进画图库”而是要能直接支撑结论。一张合格的加速比图至少包含横轴进程数、纵轴加速比、理想参考线、实测折线加数据点标记、坐标轴单位、图例。用 Python 复现一遍最省事import matplotlib.pyplot as plt p [1, 2, 4, 8, 16] s [1.00, 1.89, 3.56, 5.90, 7.65] # 实测加速比 ideal p # 理想线性参照 plt.figure(figsize(6, 4.5)) plt.plot(p, ideal, linestyle--, colorgray, labelideal S(p)p) plt.plot(p, s, markero, color#1f4e79, labelmeasured) plt.xlabel(processes / threads p) plt.ylabel(speedup S(p)) plt.xticks(p) plt.grid(alpha0.3) plt.legend() plt.tight_layout() plt.savefig(speedup.png, dpi200) # dpi 给够打印到报告里不糊参数上只有两个要点dpi不要低于 150否则插进文档会发虚tight_layout()要加避免轴标签被裁掉。真要说有什么心得就是每张图都要能回答一个问题——“这张图证明了什么”答不上来的图就删掉它只会稀释重点。最后一个习惯每次做完一组实验趁热把“原始时间、进程数、问题规模、编译选项、机器核数”记在同一张表里不要等写报告时再回忆。有一次我隔了一周才整理数据结果发现记录的编译选项和实际跑的不是一套整组数据作废重跑那半天时间纯粹是白送的。从那以后我每次开跑之前都强制先把环境信息抄进表头跑完立刻填时间再也没在这个环节上翻过车。希望帮到你。本文还有配套的精品资源点击获取