简介：这份资源是天津大学并行计算课程的配套学习资料，面向计算机专业学生、高性能计算方向的学习者以及需要系统梳理并行编程知识的技术人员，帮助其理解共享内存与分布式内存模型、掌握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(processes=4) as pool: parallel_result = pool.map(heavy_task, tasks) print("并行耗时:", time.time() - start)这段代码里，Pool(processes=4)就是叫来四个“工人”，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 里还有一步是“把所有图片按处理结果排序后再统一输出”，那排序和汇总这段就是串行瓶颈，并行只能加速前面的处理段。这时候更聪明的做法是先把能并行的部分榨干，再评估串行段是否值得优化，而不是一味堆进程。
从那以后我每次动手做并行之前，都会先问自己三个问题：任务能不能切、切完收益够不够大、串行瓶颈在哪。想清楚再写，比写完发现只快了一点点要省心得多。希望这份梳理能帮你在遇到“并行计算”这个词时，不再一头雾水，而是能一眼看出它适不适合眼前这摊活儿。
本文还有配套的精品资源，点击获取
