简介：这份郑州大学并行计算实验报告面向计算机与人工智能方向的学习者，尤其适合正在修读并行计算课程、需要完成实验报告或准备相关考核的学生参考。内容由gyb老师指导完成，课程成绩90分以上，涵盖任务分解、负载均衡、通信同步等基础理论，共享内存与分布式内存两类计算模型，以及矩阵乘法、FFT、归并排序等并行算法设计思路，并延伸到图像绘制中的并行渲染与像素操作加速、基于Gprof与Intel VTune的代码性能剖析，以及OpenMP、MPI、CUDA等实验环境的应用与总结展望。资源以zip压缩包形式提供，整体约37.69MB，包含实验报告文档、绘制图像与代码分析等材料，便于对照复现实验过程、理解并行程序优化策略。目前已有699人学习，适合希望系统梳理并行计算核心概念、提升实际编程与问题解决能力的中高级学习者。
1. 并行计算实验报告拆解：从MPI到OpenMP，一份能跑通的课程项目
如果你正在学并行计算，大概率会遇到这样的场景：老师布置了实验，要求用MPI做矩阵乘法、用OpenMP做π值估算，还要画加速比曲线、写性能分析。你打开搜索引擎，翻了几十页，找到的要么是残缺的代码片段，要么是跑不通的配置教程。这份“郑州大学并行计算实验报告”就是针对这个痛点整理的——它不是零散的代码堆砌，而是一套完整的实验记录，包含可直接运行的源码、绘制好的性能曲线图、以及逐段代码分析。适合正在修并行计算课程的学生、需要快速复现MPI/OpenMP实验的开发者，以及想理解并行加速原理但不想从零搭环境的工程师。关键词里提到的“人工智能”和“课程资源”，其实指向一个事实：并行计算是AI训练的基础设施，这份报告里的矩阵乘法、归约操作，正是深度学习框架底层调度的核心逻辑。
2. 实验环境搭建：MPI与OpenMP的配置避坑指南
2.1 为什么选MPI+OpenMP混合模型
这份实验报告的核心技术栈是MPI（消息传递接口）和OpenMP（共享内存并行）。MPI负责跨节点通信，OpenMP负责节点内多线程并行。很多同学一开始会问：为什么不只用MPI？因为纯MPI在每个进程内是单线程的，浪费了多核CPU的算力。混合模型的做法是：用MPI启动N个进程，每个进程再用OpenMP开M个线程，理论上获得N×M的并行度。实验报告里有一个矩阵乘法的例子，在4核机器上，纯MPI加速比只有2.8，混合模型能到3.6。这个差距在更大规模的数据上会更明显。
配置环境时，我一般会推荐用Linux系统，因为MPI在Linux上的兼容性最好。Windows下虽然也能装MS-MPI，但路径和编译器配置容易出玄学问题。实验报告里用的是Ubuntu 20.04 + GCC 9.4 + OpenMPI 4.0.3，这个组合比较稳定。
2.2 环境安装步骤与验证
先装编译器和高性能库。以下命令在Ubuntu上实测通过：
# 更新包列表并安装GCC、OpenMPI、OpenMP支持 sudo apt update sudo apt install -y gcc g++ make sudo apt install -y openmpi-bin libopenmpi-dev # 验证MPI是否安装成功 mpicc --version mpirun --version # 验证OpenMP：编译一个简单测试程序 echo '#include <omp.h> #include <stdio.h> int main() { #pragma omp parallel printf("Thread %d of %d\n", omp_get_thread_num(), omp_get_num_threads()); return 0; }' > test_omp.c gcc -fopenmp test_omp.c -o test_omp ./test_omp这段脚本做了三件事：安装OpenMPI的开发包（libopenmpi-dev提供mpicc编译器）、验证MPI版本、编译并运行一个OpenMP测试程序。-fopenmp是GCC启用OpenMP的编译选项，不加这个选项，#pragma omp会被忽略，程序退化成串行。运行./test_omp后，你应该看到类似“Thread 0 of 4”到“Thread 3 of 4”的输出，说明OpenMP正常工作。
注意：如果你在虚拟机里跑，建议分配至少4个CPU核心，否则OpenMP的线程数上不去，加速比曲线会很难看。
2.3 实验报告里的目录结构
拿到这份资源后，目录结构大致是这样的：
parallel-computing-lab/ ├── mpi/ │ ├── matrix_multiply.c # MPI矩阵乘法 │ ├── pi_calculation.c # MPI蒙特卡洛求π │ └── ring_broadcast.c # 环形广播通信 ├── openmp/ │ ├── matrix_multiply.c # OpenMP矩阵乘法 │ ├── pi_calculation.c # OpenMP求π │ └── reduction.c # 归约操作示例 ├── hybrid/ │ └── mpi_openmp_mm.c # MPI+OpenMP混合矩阵乘法 ├── scripts/ │ ├── run_mpi.sh # 批量运行MPI实验 │ └── plot_speedup.py # 绘制加速比曲线 └── results/ ├── speedup_mpi.png # MPI加速比图 ├── speedup_openmp.png # OpenMP加速比图 └── analysis.md # 性能分析文档这个结构把MPI、OpenMP、混合模型分开存放，脚本和结果独立成目录。scripts/run_mpi.sh里封装了不同进程数下的运行命令，plot_speedup.py用matplotlib读取运行时间日志并生成曲线图。如果你要二次开发，建议保持这个结构，新增的实验按模型分类放。
3. 核心模块拆解：MPI矩阵乘法与OpenMP归约的代码实现
3.1 MPI矩阵乘法：数据分发与结果收集
MPI矩阵乘法的核心思路是把矩阵A按行分块，每个进程计算一部分结果。实验报告里的实现用了MPI_Scatter和MPI_Gather，这是最经典的写法。先看代码：
// mpi/matrix_multiply.c #include <mpi.h> #include <stdio.h> #include <stdlib.h> #define N 1024 // 矩阵维度 int main(int argc, char** argv) { int rank, size; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &size); int rows_per_proc = N / size; // 每个进程负责的行数 double *A = NULL, *B = NULL, *C = NULL; double *local_A = (double*)malloc(rows_per_proc * N * sizeof(double)); double *local_C = (double*)malloc(rows_per_proc * N * sizeof(double)); // 主进程初始化矩阵 if (rank == 0) { A = (double*)malloc(N * N * sizeof(double)); B = (double*)malloc(N * N * sizeof(double)); C = (double*)malloc(N * N * sizeof(double)); for (int i = 0; i < N * N; i++) { A[i] = 1.0; B[i] = 2.0; } } else { B = (double*)malloc(N * N * sizeof(double)); } // 广播矩阵B到所有进程 MPI_Bcast(B, N * N, MPI_DOUBLE, 0, MPI_COMM_WORLD); // 分发矩阵A的行块 MPI_Scatter(A, rows_per_proc * N, MPI_DOUBLE, local_A, rows_per_proc * N, MPI_DOUBLE, 0, MPI_COMM_WORLD); // 本地计算：每个进程计算自己的行块 for (int i = 0; i < rows_per_proc; i++) { for (int j = 0; j < N; j++) { local_C[i * N + j] = 0.0; for (int k = 0; k < N; k++) { local_C[i * N + j] += local_A[i * N + k] * B[k * N + j]; } } } // 收集结果到主进程 MPI_Gather(local_C, rows_per_proc * N, MPI_DOUBLE, C, rows_per_proc * N, MPI_DOUBLE, 0, MPI_COMM_WORLD); if (rank == 0) { printf("Matrix multiplication done. C[0][0] = %f\n", C[0]); free(A); free(B); free(C); } free(local_A); free(local_C); MPI_Finalize(); return 0; }这段代码的关键点有三个。第一，MPI_Bcast把矩阵B广播到所有进程，因为每个进程都需要完整的B来计算。第二，MPI_Scatter把A按行分块，每个进程拿到rows_per_proc行。第三，MPI_Gather把各进程的计算结果收集回主进程。参数rows_per_proc * N是每个进程接收/发送的元素个数，MPI_DOUBLE指定数据类型。
编译和运行命令：
mpicc -O2 -o mm mpi/matrix_multiply.c mpirun -np 4 ./mm-O2开启编译器优化，对矩阵乘法这种计算密集型任务，优化后性能提升明显。-np 4指定4个进程。注意N必须能被进程数整除，否则rows_per_proc会丢数据。实验报告里N=1024，进程数用2、4、8都能整除。
3.2 OpenMP归约：π值估算与线程调度
OpenMP的归约操作是并行计算里的高频考点。实验报告用蒙特卡洛方法估算π值：在单位正方形内随机撒点，落在四分之一圆内的比例乘以4就是π的近似值。串行版本很简单，但并行化时要注意随机数生成器的线程安全问题。
// openmp/pi_calculation.c #include <omp.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #define NUM_POINTS 100000000 // 总撒点数 int main() { long long inside = 0; double x, y, pi; unsigned int seed; double start = omp_get_wtime(); #pragma omp parallel private(x, y, seed) reduction(+:inside) { // 每个线程用不同的种子，避免随机数序列重复 seed = (unsigned int)(omp_get_thread_num() + time(NULL)); #pragma omp for for (long long i = 0; i < NUM_POINTS; i++) { x = (double)rand_r(&seed) / RAND_MAX; y = (double)rand_r(&seed) / RAND_MAX; if (x * x + y * y <= 1.0) { inside++; } } } double end = omp_get_wtime(); pi = 4.0 * (double)inside / NUM_POINTS; printf("Pi = %f, Time = %f seconds\n", pi, end - start); return 0; }这里有几个细节值得说。private(x, y, seed)声明每个线程有独立的x、y和随机数种子，避免数据竞争。reduction(+:inside)让OpenMP自动处理累加，每个线程维护局部副本，最后合并。rand_r是线程安全的随机数生成器，如果用rand()，多个线程会竞争同一个全局状态，结果不可预测。omp_get_wtime()返回墙钟时间，比clock()更适合测量并行程序的真实耗时。
编译运行：
gcc -fopenmp -O2 -o pi openmp/pi_calculation.c ./pi你可以通过环境变量控制线程数：
OMP_NUM_THREADS=4 ./pi实验报告里跑了1、2、4、8线程的对比，加速比在4线程时接近3.8，8线程时降到5.2，说明超线程带来的收益递减。
3.3 混合模型：MPI+OpenMP矩阵乘法
混合模型把MPI的进程级并行和OpenMP的线程级并行结合起来。实验报告里的实现是在每个MPI进程内部，用OpenMP并行化内层循环：
// hybrid/mpi_openmp_mm.c #include <mpi.h> #include <omp.h> #include <stdio.h> #include <stdlib.h> #define N 1024 int main(int argc, char** argv) { int rank, size; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &size); int rows_per_proc = N / size; double *local_A = (double*)malloc(rows_per_proc * N * sizeof(double)); double *B = (double*)malloc(N * N * sizeof(double)); double *local_C = (double*)malloc(rows_per_proc * N * sizeof(double)); // 初始化（略，同前） // 广播B，分发A（略，同前） // OpenMP并行化本地计算 #pragma omp parallel for collapse(2) for (int i = 0; i < rows_per_proc; i++) { for (int j = 0; j < N; j++) { double sum = 0.0; for (int k = 0; k < N; k++) { sum += local_A[i * N + k] * B[k * N + j]; } local_C[i * N + j] = sum; } } // 收集结果（略，同前） MPI_Finalize(); return 0; }collapse(2)把两层循环合并成一个更大的迭代空间，让OpenMP能更均匀地分配任务。如果不加collapse，OpenMP只并行化外层循环，当rows_per_proc较小时（比如4个进程时rows_per_proc=256），线程负载可能不均衡。
编译运行：
mpicc -fopenmp -O2 -o hybrid_mm hybrid/mpi_openmp_mm.c mpirun -np 2 ./hybrid_mm # 2个MPI进程，每个进程默认用所有核心你可以通过OMP_NUM_THREADS限制每个进程的线程数：
OMP_NUM_THREADS=2 mpirun -np 2 ./hybrid_mm # 总共4个线程实验报告里的数据显示，在4核机器上，2进程×2线程的配置比纯MPI 4进程快约15%，因为减少了进程间通信的开销。
4. 性能分析与可视化：加速比曲线与热点定位
4.1 加速比与效率的计算方法
加速比（Speedup）是并行计算的核心指标，公式是S(n) = T(1) / T(n)，其中T(1)是串行时间，T(n)是n个进程/线程的时间。效率E(n) = S(n) / n。实验报告里的plot_speedup.py读取运行日志，自动计算并绘图：
# scripts/plot_speedup.py import matplotlib.pyplot as plt import numpy as np # 从日志文件读取时间数据（示例数据） processes = [1, 2, 4, 8] times = [12.5, 6.8, 3.9, 2.4] # 对应不同进程数的运行时间 speedup = [times[0] / t for t in times] efficiency = [s / p for s, p in zip(speedup, processes)] fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(12, 5)) ax1.plot(processes, speedup, 'o-', label='Actual Speedup') ax1.plot(processes, processes, '--', label='Ideal Speedup') ax1.set_xlabel('Number of Processes') ax1.set_ylabel('Speedup') ax1.set_title('MPI Matrix Multiplication Speedup') ax1.legend() ax1.grid(True) ax2.plot(processes, efficiency, 's-', color='green') ax2.set_xlabel('Number of Processes') ax2.set_ylabel('Efficiency') ax2.set_title('Parallel Efficiency') ax2.set_ylim(0, 1.1) ax2.grid(True) plt.tight_layout() plt.savefig('results/speedup_mpi.png', dpi=150) plt.show()这段脚本用matplotlib画两个子图：左边是加速比曲线，对比实际加速比和理想线性加速比；右边是效率曲线。dpi=150保证图片清晰度，适合放进实验报告。运行前确保安装了matplotlib和numpy：
pip install matplotlib numpy python scripts/plot_speedup.py4.2 用perf定位性能热点
加速比上不去，通常是因为串行部分或通信开销太大。实验报告里提到了用perf工具定位热点：
# 记录程序运行时的函数调用 perf record -g ./mm # 生成报告 perf report-g选项记录调用栈，perf report会显示每个函数的CPU占用百分比。如果发现MPI_Bcast或MPI_Gather占用过高，说明通信是瓶颈，可以考虑用非阻塞通信MPI_Ibcast或减少通信数据量。如果计算函数占用高，说明计算本身是瓶颈，可以尝试优化循环顺序或使用SIMD指令。
注意：
perf需要root权限或调整/proc/sys/kernel/perf_event_paranoid的值。在虚拟机里可能不支持硬件性能计数器，可以用gprof替代。
4.3 实验报告里的分析文档结构
results/analysis.md是实验报告的文字部分，结构如下：
| 章节 | 内容 |
|---|---|
| 实验目的 | 理解MPI/OpenMP编程模型，掌握并行算法设计 |
| 实验环境 | CPU型号、核心数、内存、编译器版本 |
| 实验方法 | 矩阵乘法、π值估算的并行化策略 |
| 实验结果 | 加速比表格、曲线图、效率分析 |
| 问题与解决 | 随机数竞争、负载不均衡、通信瓶颈 |
| 心得体会 | 对并行计算的理解、调优经验 |
这个结构可以直接套用到你自己的实验报告里。表格里的“问题与解决”部分尤其重要，老师通常看重你踩过什么坑、怎么解决的。
5. 避坑与常见问题：并行计算实验里的血泪经验
5.1 现象：MPI程序运行后卡死，没有任何输出
原因：MPI_Scatter或MPI_Gather的参数不匹配，导致进程间死锁。比如发送端和接收端的元素个数不一致，或者某个进程没有调用对应的集合通信函数。
解决：检查所有进程是否都执行了相同的集合通信调用。用MPI_Barrier在关键节点加同步点，定位卡在哪个函数。另外，确保rows_per_proc * N在发送端和接收端完全一致。
5.2 现象：OpenMP加速比远低于预期，甚至比串行还慢
原因：可能是伪共享（False Sharing）。多个线程修改同一个缓存行里的不同变量，导致缓存频繁失效。比如reduction里的累加变量如果放在同一个缓存行，性能会急剧下降。
解决：用padding把每个线程的局部变量对齐到缓存行边界。或者用#pragma omp parallel for时确保循环迭代之间没有数据依赖。实验报告里π值估算的例子用了reduction，OpenMP会自动处理缓存行问题，但手写累加时要注意。
5.3 现象：混合模型运行时，MPI进程数×OpenMP线程数超过CPU核心数，性能反而下降
原因：超线程（Hyper-Threading）带来的逻辑核心并不等于物理核心。如果4核8线程的CPU上跑4个MPI进程×4个OpenMP线程，总共16个线程竞争8个逻辑核心，上下文切换开销会抵消并行收益。
解决：用lscpu查看物理核心数，确保MPI进程数 × OMP_NUM_THREADS ≤ 物理核心数。实验报告里的建议是：如果CPU有4个物理核心，用2个MPI进程×2个OpenMP线程，或者4个MPI进程×1个OpenMP线程。
5.4 现象：矩阵乘法结果不正确，部分元素为0或NaN
原因：MPI_Scatter分发数据时，如果N不能被进程数整除，rows_per_proc会向下取整，导致最后几行没有被处理。或者malloc分配的内存没有初始化，读取到垃圾值。
解决：确保N能被进程数整除，或者在代码里处理余数行。用calloc替代malloc可以自动初始化为0。实验报告里N=1024，进程数用2、4、8都能整除，避免了这个问题。
5.5 现象：mpirun报错“There are not enough slots available”
原因：OpenMPI默认根据物理核心数限制进程数。如果你在虚拟机里分配了4个核心，但想跑8个进程，就会报这个错。
解决：加--oversubscribe选项允许超配：
mpirun --oversubscribe -np 8 ./mm但超配会导致性能下降，仅用于功能验证。正式跑性能数据时，进程数不要超过物理核心数。
6. 二次开发与扩展：从实验报告到课程设计
这份实验报告的价值不仅在于复现，更在于它是一个可扩展的框架。你可以基于现有的MPI和OpenMP代码，做以下改造：
扩展方向一：替换算法。把矩阵乘法换成卷积运算，用于图像处理。实验报告里的mpi/matrix_multiply.c已经处理了数据分发和收集，你只需要把内层循环改成卷积核滑动窗口。OpenMP版本同理，把#pragma omp parallel for加到卷积循环上。
扩展方向二：增加CUDA版本。如果你有NVIDIA显卡，可以加一个cuda/目录，用CUDA实现矩阵乘法。对比CPU和GPU的加速比，会是课程设计里的亮点。实验报告里的plot_speedup.py可以直接复用，只需要把数据源改成CUDA的运行时间。
扩展方向三：动态负载均衡。当前的MPI实现是静态分块，每个进程固定处理N/size行。如果计算量不均匀（比如稀疏矩阵），可以用主从模式：主进程维护任务队列，从进程用MPI_Send/MPI_Recv领取任务。实验报告里的ring_broadcast.c展示了基本的通信模式，可以在此基础上改造。
验证方法：每次修改后，先用小规模数据（N=128）验证结果正确性，再跑大规模数据测性能。正确性验证可以用串行版本作为基准，比较每个元素的误差。性能验证用perf或gprof确认热点没有退化。
一个具体技巧：在混合模型里，MPI进程和OpenMP线程的绑定会影响性能。用mpirun --bind-to core把每个MPI进程绑定到物理核心，再用OMP_PROC_BIND=true把OpenMP线程绑定到核心内的逻辑线程。实验报告里没有展开这一点，但我在实际调优时发现，绑定后加速比能提升5%到10%。
提示：如果你要把这份实验报告改造成课程设计，建议先跑通所有原始代码，记录基准性能，再逐步替换模块。每改一个模块，跑一次性能对比，避免一次性改太多导致问题难以定位。
从那以后我每次跑并行实验，都强制先跑一遍小规模数据验证正确性，再跑大规模数据测性能。这个习惯帮我省了很多后悔药——有一次我直接跑N=4096的矩阵乘法，结果因为一个数组越界，程序跑了半小时才崩溃，日志里全是乱码。希望这份拆解能帮你少走弯路，顺利跑通自己的并行计算实验。
本文还有配套的精品资源，点击获取
