为什么学习并行计算需要了解硬件

Mechanisms used to implement abstractions efficiently

这里说的是「计算机系统里实现抽象的机制」。抽象就是我们写程序时看到的接口或功能，而底层需要硬件去实现。

• Performance characteristics of implementations

  不同的硬件实现方式会直接影响性能（比如：多核 CPU vs GPU vs 分布式集群，通信速度、内存带宽差异很大）。

• Design trade-offs: performance vs. convenience vs. cost

  在设计硬件和系统时，通常要做取舍：

  • 性能（Performance）更高 → 可能更贵，也更复杂。
  • 方便（Convenience）更强 → 可能会牺牲效率。
  • 成本（Cost） → 限制了你能选择什么样的硬件。

Why do I need to know about hardware?

• 因为硬件特性真的很重要

  比如：如果 CPU 和内存之间通信很慢，那么即使算法再好，性能也会被拖慢。（前面提到的 demo 里可能演示过通信延迟的问题。）

• 因为你关心效率和性能

  你在写并行程序，目标通常就是「更快」。要达到这一点，就必须知道底层硬件如何调度、通信、共享资源，否则写出来的程序可能效率低甚至更慢。

“快”不等于“高效” (FAST != EFFICIENT)

一台有 10 个处理器 的电脑，如果你的程序只加速了 2 倍，那其实效率很低。

• 理想情况：用 10 个处理器 → 最多能接近 10 倍加速（忽略通信和同步开销）。
• 实际只得到 2 倍 → 说明硬件大部分资源都浪费了（可能线程没有合理分工、通信开销太大等）。

程序员的视角

• 你要尽量利用硬件已经提供的能力，比如多核、缓存、SIMD 指令等。
• 问题：代码是否能让所有处理器都有事情做？
• 是否减少了同步等待、通信延迟？

硬件设计师的视角

• 他们关心的是：在设计芯片时，投入的资源（硅面积、功耗、成本）有没有被程序员利用起来。
• 比如：我在芯片上设计了 10 个核，但如果程序员写的程序只能用到 2 个核，那这 8 个核就浪费了。
• 设计时要权衡：性能 vs 成本（更高性能可能需要更大硅片面积、更高功耗）。

理器执行指令 (processor executes instructions)

1. Fetch / Decode （取指令 + 解码）

• 作用：确定下一条要执行的指令是什么。
• 流程：
  • 从内存或程序计数器（PC, Program Counter）取出一条指令。
  • 解码这条指令，弄清楚它是加法、减法、逻辑运算还是数据移动。

👉 可以理解成「看说明书，知道下一步要干嘛」。

1. Execution Context （执行上下文）

• 包括一堆 寄存器 (Registers)：R0, R1, R2, R3 …
• 作用：保存程序运行时的状态，比如：
  • 指令操作的输入（操作数）。
  • 指令执行的结果（输出）。

👉 可以理解成「工人的工作台」，放着原料（输入数据）和成品（结果）。

1. ALU (Execution Unit, 算术逻辑单元)

• 作用：执行指令中描述的操作。
• 可能修改：
  • 寄存器 (registers) 中的值（例如：R1 = R2 + R3）。
  • 内存 (memory) 中的数据（例如：把寄存器的结果写回内存）。

👉 就是「真正做事的工人」，执行加减乘除、逻辑判断等。

超标量思想 (Superscalar Execution)

处理器能够在一个时钟周期里同时发射（dispatch）多条独立指令到不同的执行单元（ALU/乘法器/加法器等），并行执行它们。

• 关键点：处理器（或编译器）要自动发现哪些指令是 独立的（没有数据依赖）。
• 独立指令 → 可以并行执行。
• 有依赖的指令 → 必须等待。

什么是 stall？

ld r0, mem[r2]   ; 把内存[mem[r2]]的数据加载到寄存器r0
ld r1, mem[r3]   ; 把内存[mem[r3]]的数据加载到寄存器r1
add r0, r0, r1   ; r0 = r0 + r1

• 这里 add 指令依赖前两条指令加载的数据。
• 但是内存访问很慢（几百个 CPU 周期）。
• 所以 CPU 必须等前两条 ld 完成，才能执行 add。
• 👉 这就造成了 stall（停顿）。