简介这份资源是天津大学并行计算课程的配套学习资料面向计算机专业学生、高性能计算方向的学习者以及需要系统梳理并行编程知识的技术人员帮助其理解共享内存与分布式内存模型、掌握OpenMP与MPI等并行编程工具并具备将串行算法改造为并行程序的能力。压缩包为zip格式整体约44.18MB文件总数与类型明细上游暂未提供从内容看应包含课程讲义、实验报告与复习总结等材料。目前已有1587人学习具备一定的参考价值。资料围绕并行计算基础、负载均衡、同步与互斥、分治与归约扫描等并行算法设计策略展开并结合Amdahl定律与Gustafson定律进行性能分析实验部分涉及并行排序、矩阵运算、图形渲染等场景复习总结则梳理考试重点与解题思路便于读者对照实验代码巩固理论、查漏补缺。1. 并行计算到底在算什么从“一个人搬砖”到“一群人搬砖”的直觉你第一次听到“并行计算”这四个字大概率是在某门课、某个项目介绍或者一份资料标题里。它听起来很唬人像是只有超级计算机才配谈的东西。但说白了它解决的是一个特别朴素的问题活儿太多一个人干不完怎么办打个比方。你要把一万块砖从楼下搬到楼上。一个人搬来回一万趟累死也得好几天。但如果你叫来十个人每人搬一千块时间立刻缩到十分之一。并行计算干的就是这件事——只不过搬的不是砖是计算任务叫来的不是人是 CPU 核心、GPU 线程或者一整个计算集群。它的核心思想就一句话把一个大任务拆成许多能同时干的小任务让多个计算单元一起动手从而缩短总时间。为什么值得搞懂因为今天你用的手机、电脑、服务器几乎全是多核的。单核性能早就撞上了物理天花板厂商拼的是“核多不多、能不能协同”。不懂并行你写出来的程序可能只用到一个核剩下七个核在旁边看戏——这就是很多“玄学卡顿”的根源。并行计算不是什么高冷概念它是理解现代硬件如何真正干活的一把钥匙。2. 为什么非要并行单核撞墙之后算力只能靠“人多”2.1 频率上不去了核数成了新赛道早年间提升算力很简单把 CPU 主频往上拉就行。但从十几年前开始这条路走不动了。主频越高发热和功耗越夸张散热压不住芯片也扛不住。工程师们换了个思路既然单个核心快不了那就多放几个核心让它们同时干活。于是双核、四核、八核乃至几十核的处理器成了常态。这带来一个直接后果硬件已经把“人多”的条件给你了但软件得跟得上。一个只按“一个人搬砖”思路写的程序放到八核机器上依然只有一个核在忙。并行计算就是教你怎么把任务分出去让多出来的核真正派上用场。换句话说并行不是可选项而是榨干现代硬件性能的必经之路。2.2 两种“人多”的方式多进程与多线程让多个计算单元同时干活常见的有两条路。一条叫多进程每个进程是独立的“工人”各有各的内存空间互不干扰适合把大任务切成几块互不依赖的子任务。另一条叫多线程多个线程共享同一块内存像同一个车间里的几个工人共用一张工作台沟通方便但也容易互相踩脚。用 Python 写个最直观的对比感受一下“串行”和“并行”的差别import time from multiprocessing import Pool def heavy_task(n): # 模拟一段耗时的计算比如累加 total 0 for i in range(n): total i * i return total if __name__ __main__: tasks [10_000_000] * 4 # 四个相同的重任务 # 串行一个接一个地算 start time.time() serial_result [heavy_task(t) for t in tasks] print(串行耗时:, time.time() - start) # 并行开四个进程同时算 start time.time() with Pool(processes4) as pool: parallel_result pool.map(heavy_task, tasks) print(并行耗时:, time.time() - start)这段代码里Pool(processes4)就是叫来四个“工人”pool.map把四个任务分给它们同时干。参数processes控制工人数量一般设成 CPU 核心数比较合适。跑下来你会发现并行耗时明显更短——这就是并行的直接收益。当然真实场景远比这复杂任务之间可能有依赖、要共享数据那就得换更精细的拆分方式。2.3 并行的收益不是白来的阿姆达尔定律的提醒并行不是万能加速药。有个很实在的规律叫阿姆达尔定律一个程序里能并行的部分越多加速比才越高如果有一大段必须串行执行那不管你加多少核总时间也降不下去。打个比方十个人搬砖很快但如果只有一把钥匙、必须排队开门那开门这段时间谁也帮不上忙。这提醒我们做并行优化先找“串行瓶颈”在哪。很多时候程序慢不是核不够而是某一段逻辑天生只能一个人干。盲目加线程、加进程可能只是让更多工人在门口排队反而增加调度开销。理解这一点你就不会把并行当成“无脑加速开关”而是带着判断去用它。3. 并行计算和它的“亲戚们”别把并发、分布式、向量化混成一锅3.1 并行与并发一个在“同时干”一个在“轮流干”这是初学者最容易混的一对词。并行强调的是同一时刻真的有多个任务在同时推进比如四核同时算四份数据。并发强调的是“看起来同时在处理多件事”但底层可能只有一个核靠快速切换轮流干就像一个人同时接三个电话其实是来回切换。为什么容易混因为日常口语里这俩词几乎不分。怎么区分看硬件并行需要多个物理计算单元真正同时工作并发是一种任务组织方式单核也能并发。写程序时并发关心的是“怎么把任务调度得井井有条”并行关心的是“怎么让多个单元同时出力”。两者常常一起用但概念不能划等号。3.2 并行与分布式一个在“一间屋”一个在“几栋楼”并行计算通常指同一台机器内的多个核心协同共享内存、通信极快。分布式计算则是把任务分散到多台机器上机器之间靠网络通信延迟高、还可能断线。打个比方并行是同一个车间里的工人协作喊一嗓子就听见分布式是几个城市的分厂协同得靠电话和物流。为什么混因为两者目标都是“多算力一起干活”。区分的关键在通信成本和故障模型并行里内存访问是纳秒级分布式里网络往返是毫秒级甚至更久而且分布式还得考虑某台机器挂了怎么办。所以同一套拆分思路落到分布式上要额外处理数据一致性和容错不能照搬。3.3 并行与向量化一个靠“人多”一个靠“手快”向量化是指让一条指令同时处理多个数据比如 SIMD 技术一个操作搞定一组数。它不增加“工人数量”而是让每个工人一次搬多块砖。并行则是增加工人。两者可以叠加多个核心各自再做向量化性能还能再上一层。容易混是因为都叫“加速”。区分看粒度向量化是指令级的细粒度并行通常由编译器或特定写法触发并行是任务级或线程级的粗粒度拆分需要你主动设计任务怎么分。搞不清这点你可能以为写了循环就自动并行了其实编译器只是帮你做了向量化核还是只用了一个。3.4 常见误区核越多越快、线程越多越好最后一个高频误区以为加核、加线程就一定更快。实际上线程太多会带来上下文切换开销进程太多会争抢内存带宽任务拆得太碎则调度成本超过计算本身。就像搬砖叫来一百个人楼梯口挤成一团反而谁都动不了。怎么避开先测量再优化用工具看程序到底卡在哪是计算密集还是等待密集串行部分占多少。然后小步试线程数从核心数起步观察耗时变化找到拐点。记住并行是手段不是目的目标是总时间更短而不是数字上“看起来更热闹”。4. 什么时候该上并行什么时候别硬上一份判断清单4.1 适合并行的场景长什么样判断一个任务该不该并行先看它能不能被“切开”。如果任务能自然拆成许多互不依赖的小块比如对一大批图片做同样的滤镜处理、对海量数据做独立统计、矩阵乘法里各元素的计算那并行就是天作之合。这类任务有个共同点每块的计算量足够大大到调度开销可以忽略。再看数据规模。数据量小的时候串行几毫秒就跑完了你花力气拆任务、开进程光启动开销就比计算还长纯属折腾。数据量大、单次计算重并行的收益才明显。还有一个信号程序跑起来时你打开任务管理器发现只有一个核在满负荷其余在摸鱼——这就是典型的“该并行却没并行”。4.2 不适合硬上的情况有些任务天生串行。比如每一步都依赖上一步结果的计算像递推、某些图算法你没法让第二步和第一步同时跑。还有些任务共享状态极多加锁、同步的成本高到把并行收益吃光这时候硬上并行程序不但不快还可能因为死锁、竞态条件翻车调试起来全是血泪经验。另外I/O 密集型的任务要分清如果瓶颈在读写磁盘或网络等待那多开线程可能有用让等待重叠但这更接近并发调度而非纯计算并行。别把“等得久”误当成“算得慢”方向错了加多少核都白搭。判断维度适合并行不适合硬上任务依赖子任务相互独立强前后依赖、必须串行数据规模数据量大、单次计算重数据极小、秒级完成共享状态少量或可分区大量共享、频繁加锁瓶颈类型计算密集I/O 等待为主或串行段过长4.3 一个具体例子图像批处理的取舍假设某图像处理 Demo 要对上万张图片做同一种降噪处理。每张图互不相关单张处理耗时几十毫秒这就是典型的可并行任务。做法是把图片列表切成若干份开多个进程各处理一份进程数设成核心数附近观察耗时找最优值。这里的关键不是代码多复杂而是“切得合理”切太细进程调度开销上来切太粗负载不均有的核早早干完在等。反过来如果这个 Demo 里还有一步是“把所有图片按处理结果排序后再统一输出”那排序和汇总这段就是串行瓶颈并行只能加速前面的处理段。这时候更聪明的做法是先把能并行的部分榨干再评估串行段是否值得优化而不是一味堆进程。从那以后我每次动手做并行之前都会先问自己三个问题任务能不能切、切完收益够不够大、串行瓶颈在哪。想清楚再写比写完发现只快了一点点要省心得多。希望这份梳理能帮你在遇到“并行计算”这个词时不再一头雾水而是能一眼看出它适不适合眼前这摊活儿。本文还有配套的精品资源点击获取