电子科技大学分布式并行计算MPI实验：环境搭建、矩阵并行与性能验证全流程

简介这份资源是电子科技大学分布式并行计算课程的MPI实验报告合集面向正在学习并行编程、准备课程实验或希望入门高性能计算的学生与开发者。内容围绕MPI标准展开涵盖点对点通信、集合通信、进程管理、数据分布、并行算法设计、性能分析与调优、结果验证及死锁等错误处理机制能帮助读者理解如何将排序、搜索、矩阵运算等经典算法改造为并行版本。压缩包为7z格式整体约902KB文件总数与类型明细上游暂未提供但体量轻便便于快速查阅与本地留存。目前已有1448人学习下载说明该实验报告在同类课程资料中具备一定参考热度。对于需要完成MPI实验、梳理通信原语用法或对照实验环境搭建思路的读者这份报告可作为实践参考辅助理解并行程序从设计到验证的完整流程。1. 电子科技大学分布式并行计算 MPI 实验从环境配置到性能验证的完整路径如果你正在搜索「电子科技大学分布式并行计算-MPI实验报告」大概率是两种情况要么你正在修这门课需要把实验跑通并写出有数据支撑的报告要么你在自学 MPI想找一套贴近高校教学体系的完整流程来练手。不管哪种核心诉求都一样——把 MPI 环境搭起来把并行程序跑起来把加速比算出来把报告写扎实。MPIMessage Passing Interface是分布式内存并行编程的事实标准也是高性能计算课程绕不开的基础。电子科技大学这门课的实验通常覆盖点对点通信、集合通信、矩阵并行计算和性能分析几个层次。很多人卡在第一步Ubuntu 下 MPI 配置失败mpicc 找不到或者多机免密登录没配好程序跑不起来。这篇内容就按「环境搭建 → 核心实验复现 → 性能验证 → 踩坑排查」的顺序把每个环节的命令、参数和判断标准讲清楚让你能直接照着做。2. MPI 环境搭建与第一个并行程序Ubuntu 下从零到跑通2.1 选 MPICH 还是 OpenMPI课程实验的选型判断高校 MPI 实验最常用的两个实现是 MPICH 和 OpenMPI。电子科技大学这类课程的实验指导书通常不会强制指定但实际做下来有几个判断依据。MPICH 的优势是轻量、稳定、编译快适合单机多进程的实验场景。OpenMPI 的进程管理和网络通信层更成熟多机实验时配置更灵活但依赖也更多。如果你只是单机跑实验、验证算法正确性和加速比MPICH 完全够用而且 Ubuntu 下apt install mpich一条命令就能装好。如果实验要求多节点集群或者后续要对接 Slurm 调度器OpenMPI 更合适。我一般建议先装 MPICH 把单机实验全部跑通确认算法和代码没问题再换 OpenMPI 做多机扩展。这样出问题时排查范围小不会一上来就被网络配置和进程管理搅在一起。安装命令如下# 更新包索引 sudo apt update # 安装 MPICH 及其编译工具链 sudo apt install -y mpich libmpich-dev # 验证安装查看 mpicc 和 mpiexec 版本 mpicc --version mpiexec --version安装完成后which mpicc应该输出/usr/bin/mpicc。如果输出为空说明 PATH 没配好检查/etc/environment或 shell 的配置文件。提示如果你之前装过 OpenMPI先sudo apt remove openmpi-bin libopenmpi-dev卸载干净否则 mpicc 可能指向错误的实现编译出来的程序运行时报错。2.2 第一个 MPI 程序进程通信的最小验证环境装好后先用一个最小程序验证 MPI 能正常工作。这个程序做两件事每个进程打印自己的 rank 和总进程数然后从 0 号进程发一条消息给 1 号进程。#include mpi.h #include stdio.h #include string.h int main(int argc, char** argv) { int rank, size; MPI_Init(argc, argv); // 初始化 MPI 环境 MPI_Comm_rank(MPI_COMM_WORLD, rank); // 获取当前进程编号 MPI_Comm_size(MPI_COMM_WORLD, size); // 获取总进程数 printf(Hello from rank %d of %d\n, rank, size); if (size 2) { if (rank 0) { char msg[] ping; MPI_Send(msg, strlen(msg)1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); printf(Rank 0 sent: %s\n, msg); } else if (rank 1) { char buf[16]; MPI_Recv(buf, 16, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); printf(Rank 1 received: %s\n, buf); } } MPI_Finalize(); // 清理 MPI 环境 return 0; }编译和运行mpicc -o hello_mpi hello_mpi.c mpiexec -n 4 ./hello_mpi-n 4指定启动 4 个进程。运行后你会看到 4 行 Hello 输出以及 rank 0 发送、rank 1 接收的消息。这里的关键参数是MPI_Send的 count 和 datatypestrlen(msg)1把字符串结束符也发过去接收端才能正确打印。如果只发strlen(msg)接收端缓冲区不会自动补\0打印出来可能是乱码。MPI_Recv的最后一个参数MPI_STATUS_IGNORE表示不关心发送方的具体信息。如果你需要知道实际收到了多少数据可以传一个MPI_Status结构体进去然后读status.MPI_COUNT。这个程序跑通说明 MPI 环境没问题可以进入正式实验。3. 点对点与集合通信实验矩阵向量乘法的并行实现3.1 矩阵向量乘法的数据划分策略矩阵向量乘法是并行计算实验里最经典的题目y A * x其中 A 是 N×N 矩阵x 是 N 维向量y 是结果向量。串行算法就是两层循环复杂度 O(N²)。并行化的核心思路是把矩阵按行分块每个进程负责一部分行计算出对应的 y 分量。数据划分有两种常见方式按行块划分block distribution和循环划分cyclic distribution。按行块划分是把连续的若干行分给一个进程实现简单通信模式清晰。循环划分是第 i 行分给第 i mod p 个进程负载更均衡但通信模式复杂。课程实验通常用按行块划分就够了。假设 N1024进程数 p4每个进程分到 256 行。进程 0 拿第 0~255 行进程 1 拿第 256~511 行以此类推。每个进程需要完整的向量 x 来计算自己那部分行的点积所以通信模式是初始时进程 0 把 x 广播给所有进程然后各进程独立计算最后把结果 y 的各段收集回进程 0。3.2 完整代码与 MPI 集合通信函数的使用#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; // 每个进程负责的行数 int start_row rank * rows_per_proc; // 分配本地矩阵块和向量 double *local_A (double*)malloc(rows_per_proc * N * sizeof(double)); double *x (double*)malloc(N * sizeof(double)); double *local_y (double*)malloc(rows_per_proc * sizeof(double)); double *y NULL; // 初始化为简化所有进程用相同规则生成数据 for (int i 0; i rows_per_proc; i) for (int j 0; j N; j) local_A[i*N j] (start_row i j) % 100; for (int j 0; j N; j) x[j] j % 50; // 广播向量 x 给所有进程 MPI_Bcast(x, N, MPI_DOUBLE, 0, MPI_COMM_WORLD); // 本地计算每个进程计算自己那部分 y double t_start MPI_Wtime(); for (int i 0; i rows_per_proc; i) { local_y[i] 0.0; for (int j 0; j N; j) { local_y[i] local_A[i*N j] * x[j]; } } double t_end MPI_Wtime(); // 收集结果到进程 0 if (rank 0) y (double*)malloc(N * sizeof(double)); MPI_Gather(local_y, rows_per_proc, MPI_DOUBLE, y, rows_per_proc, MPI_DOUBLE, 0, MPI_COMM_WORLD); if (rank 0) { printf(N%d, procs%d, time%.6f sec\n, N, size, t_end - t_start); // 验证前几个结果 for (int i 0; i 5; i) printf(y[%d] %.2f\n, i, y[i]); } free(local_A); free(x); free(local_y); if (y) free(y); MPI_Finalize(); return 0; }编译运行mpicc -O2 -o matvec matvec.c mpiexec -n 4 ./matvec这里用了两个关键集合通信函数。MPI_Bcast把进程 0 的向量 x 广播给所有进程参数依次是缓冲区、元素个数、数据类型、根进程编号、通信域。MPI_Gather把各进程的 local_y 收集到进程 0 的 y 数组中注意发送端 count 是rows_per_proc接收端 count 也是rows_per_proc表示从每个进程收这么多。MPI_Wtime()返回墙钟时间用来测并行计算部分的耗时。注意这里只测了本地计算循环没算通信时间。如果要测总时间把MPI_Bcast之前和MPI_Gather之后的时间也记下来。3.3 加速比计算与结果验证跑完 4 进程后再用 1 进程跑一次同样的代码得到串行时间 T1 和并行时间 Tp加速比 S T1 / Tp。理想情况下 S 接近 p但实际上通信开销、负载不均衡、内存带宽限制都会让 S 低于 p。验证结果正确性的方法把并行计算的 y 向量和串行版本逐元素对比误差应该在浮点精度范围内比如 1e-10。如果误差很大检查数据划分是否覆盖了所有行或者MPI_Gather的 count 参数是否匹配。一个常见的翻车点是N 不能被进程数整除时rows_per_proc N / size会丢掉余数行。比如 N1000p3每个进程分到 333 行还剩 1 行没人算。解决办法是用MPI_Scatterv和MPI_Gatherv处理不等长数据块或者简单点让 N 取进程数的整数倍。4. 性能验证与多机扩展从单机多进程到真实集群4.1 加速比与效率的测量方法性能验证是实验报告的核心部分。你需要至少测三组数据不同进程数下的运行时间、加速比、并行效率。并行效率 E S / p衡量每个进程的平均贡献。测量时要注意几个细节。第一矩阵规模要足够大否则计算时间太短通信开销占比过高加速比曲线会很难看。N1024 时单进程计算大概几十毫秒N4096 时能到秒级更适合做性能分析。第二每个配置至少跑 3 次取平均值避免系统抖动。第三确保所有进程在同一台机器上排除网络因素。一个典型的加速比表格进程数运行时间(s)加速比并行效率12.341.00100%21.221.9296%40.683.4486%80.415.7171%效率随进程数下降是正常的因为通信开销随进程数增加而每个进程的计算量减少。如果效率下降特别快比如 4 进程就掉到 50% 以下检查是不是通信量太大或者负载不均衡。4.2 多机 MPI 配置免密登录与 hostfile单机跑通后如果实验要求多机需要配置 SSH 免密登录和 hostfile。假设你有两台机器 node1 和 node2IP 分别是 192.168.1.101 和 192.168.1.102。第一步在每台机器上安装相同版本的 MPICH 或 OpenMPI。版本必须一致否则通信协议可能不兼容。第二步配置 SSH 免密登录。在 node1 上生成密钥对把公钥复制到 node2ssh-keygen -t rsa -N -f ~/.ssh/id_rsa ssh-copy-id user192.168.1.102 ssh user192.168.1.102 echo ok # 验证免密登录第三步创建 hostfile列出所有节点和槽位# hostfile 内容 192.168.1.101 slots4 192.168.1.102 slots4第四步用 mpiexec 指定 hostfile 启动mpiexec -f hostfile -n 8 ./matvec如果报错Permission denied或Connection refused检查 SSH 配置和防火墙。如果报错mpiexec: command not found说明远程节点的 PATH 没配好在 hostfile 里加上env PATH/usr/bin:$PATH或者用绝对路径。注意多机实验时确保所有节点的时钟同步用 NTP否则 MPI_Wtime 测出来的时间可能不一致影响性能分析。5. MPI 实验避坑与排查那些让实验报告翻车的细节5.1 编译报错 undefined reference to MPI_Init现象mpicc编译时提示undefined reference to MPI_Init但明明已经装了 MPICH。原因系统里同时存在多个 MPI 实现mpicc指向了 OpenMPI但链接库路径不对或者手动用gcc编译时没加-lmpi。解决用which mpicc确认编译器路径用mpicc -show查看实际的编译和链接命令。如果确实混装了卸载不需要的那个或者用update-alternatives切换默认实现。5.2 mpiexec 启动后卡死无输出现象mpiexec -n 4 ./program运行后没有任何输出程序像卡住了。原因最常见的是MPI_Send和MPI_Recv不匹配。比如进程 0 发消息给进程 1但进程 1 在等进程 2 的消息互相等待导致死锁。另一种可能是缓冲区太小MPI_Recv的 count 小于实际发送的数据量MPI 默认会截断并报错但如果错误处理被禁用可能直接挂起。解决检查所有 Send/Recv 的 rank、tag、count 是否配对。用MPI_Comm_set_errhandler(MPI_COMM_WORLD, MPI_ERRORS_RETURN)让 MPI 返回错误码而不是直接终止方便定位。小规模测试时先用-n 2跑确认基本通信没问题再扩大。5.3 加速比超过进程数现象测出来 4 进程的加速比是 5.2比理想值还高。原因串行版本和并行版本的计算逻辑不一致。比如串行版本用了-O0编译并行版本用了-O2编译器优化差异导致串行时间偏大。或者串行版本包含了数据初始化时间而并行版本没算进去。解决确保串行和并行版本用相同的编译选项计时范围一致。串行版本可以用mpiexec -n 1跑同一个程序这样代码逻辑和编译选项完全一致只是进程数不同。5.4 多机实验时进程分配不均现象hostfile 里两台机器各 4 槽位但 8 个进程全跑在 node1 上node2 空闲。原因MPI 的进程调度策略默认可能偏向本地节点。MPICH 用-ppn参数控制每节点进程数OpenMPI 用--map-by或-npernode。解决MPICH 下用mpiexec -f hostfile -n 8 -ppn 4 ./program强制每节点 4 个进程。OpenMPI 下用mpiexec --hostfile hostfile -n 8 --map-by node ./program按节点轮询分配。5.5 实验结果每次运行都不一样现象同样的代码和进程数跑三次得到三个不同的时间波动超过 20%。原因系统负载波动、CPU 频率调节、缓存效应都可能导致。实验室机器上可能还有其他人在跑任务。解决跑性能测试前用top确认没有其他重负载进程。用cpupower frequency-set -g performance把 CPU 调成性能模式避免频率调节干扰。每个配置至少跑 5 次去掉最高最低值取平均。如果波动仍然很大检查是不是内存分配失败导致 swap用free -h看内存使用情况。6. 把实验报告写出技术深度数据可视化与可复现的验证脚本实验报告要拿高分光贴代码和截图不够得有数据分析和可复现的验证流程。我一般会写一个自动化脚本把所有进程数配置跑一遍自动记录时间、算加速比、生成 CSV然后用 Python 画图。#!/bin/bash # run_benchmark.sh - 自动跑不同进程数并记录结果 echo procs,time results.csv for p in 1 2 4 8; do t$(mpiexec -n $p ./matvec | grep time | awk -Ftime {print $2} | awk {print $1}) echo $p,$t results.csv echo procs$p time$t done这个脚本把每次运行的时间追加到 CSV 文件。注意grep和awk的用法要根据你程序的输出格式调整。跑完后用 Python 读取 CSV 画加速比曲线import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(results.csv) t1 df[df[procs] 1][time].values[0] df[speedup] t1 / df[time] df[efficiency] df[speedup] / df[procs] fig, ax1 plt.subplots() ax1.plot(df[procs], df[speedup], o-, labelSpeedup) ax1.plot(df[procs], df[procs], --, labelIdeal) ax1.set_xlabel(Processes) ax1.set_ylabel(Speedup) ax1.legend() plt.savefig(speedup.png, dpi150)这张图能直观展示实际加速比和理想加速比的差距报告里配上分析文字说明差距来自通信开销和负载不均衡比单纯列数据有说服力。验证脚本的可复现性也很重要。把编译命令、运行命令、环境版本都写进一个README或者脚本注释里别人拿到你的代码能直接跑出相同结果。我习惯在实验报告附录里放一个Makefile把编译和测试命令都封装好CC mpicc CFLAGS -O2 -Wall TARGET matvec all: $(TARGET) $(TARGET): matvec.c $(CC) $(CFLAGS) -o $(TARGET) matvec.c test: $(TARGET) mpiexec -n 4 ./$(TARGET) clean: rm -f $(TARGET) results.csv这样评阅老师或者同学拿到你的实验包make make test就能复现省去环境配置的沟通成本。最后说一个我踩过的坑有一次实验报告里加速比数据特别漂亮但老师一问「你的串行时间是怎么测的」发现我用的是理论计算量除以单核峰值性能估算的不是实际跑的。这种数据在答辩时很容易被追问到崩。后来我养成习惯所有性能数据必须来自实际运行脚本自动记录原始日志保留这样任何数据都能追溯到具体的命令和输出。希望帮到你。本文还有配套的精品资源点击获取