Lecture 18: Transactional Memory (Part II) + Course Wrap Up（日期：Dec 04）

目录 · ← l17 · appendix →

Lecture 18: Transactional Memory (Part II) + Course Wrap Up（日期：Dec 04）

概述：本讲先完成事务内存（TM）的”实现篇”：介绍 TM 设计空间中已提出的代表性 STM 与 HTM 系统（TL2、OSTM、Intel STM、TCC、LTM/VTM、LogTM），深入 STM 的软件实现细节（事务描述符/事务记录、基于时间戳的 McRT 算法、软件 barrier 及其编译优化、STM 慢的原因），再进入 HTM：缓存中的 R/W 位元版本管理、基于 cache coherence 协议的冲突检测、Intel Haswell RTM 指令，以及把 TM 当作一致性机制的 TCC 例子。最后是课程收尾：总结 CS149 的核心议题（识别并行性、调度、通信、局部性）与学完之后的进阶方向（CS217、CS/EE 282、CS348K、科研机会），并以 Ask Me Anything 收场。思考题部分改为”关于课程整体”的反思题。

一、核心概念与定义

1. TM 实现设计空间（Data Versioning × Conflict Detection × Granularity）

定义：所有 TM 实现都要回答两个问题（第 17 讲已述）：数据版本策略（eager/lazy）与冲突检测策略（pessimistic/optimistic），再加上检测粒度（object/word/cache-line）。幻灯片按此给出现有系统地图：

软件 TM： Sun TL2        = lazy 版本 + optimistic 检测（读/写）
           MS OSTM       = lazy 版本 + optimistic(读)/pessimistic(写)
           Intel STM     = eager 版本 + optimistic(读)/pessimistic(写)；
                           eager 版本 + pessimistic(读/写)
硬件 TM： Stanford TCC   = lazy + optimistic
           MIT LTM / Intel VTM = lazy + pessimistic
           Wisconsin LogTM = eager + pessimistic（与常规 cache coherence 最容易结合）

要点（幻灯片原话）：最优设计仍是开放问题（optimal design remains an open question），对 HW、SW、hybrid 三种形态答案可能各不相同。
现实类比：同一门课程（TM）不同老师（系统）的教案：有的先写黑板再擦（eager），有的先在草稿纸上写（lazy）；有的每讲一句就查纪律（pessimistic），有的下课才点名（optimistic）——没有公认最好的教法。

2. STM Barrier（软件事务屏障 / 插桩代码）

定义：编译器把 atomic { } 里的每个内存访问替换成一次 STM 运行时的函数调用（如 tmRead/tmWr/tmTxnBegin/tmTxnCommit），这些插桩代码（instrumentation）负责版本管理、读集/写集跟踪、提交等簿记。因为同一函数可能在事务内外都被调用，STM 需要函数克隆（function cloning）或动态翻译（dynamic translation）来生成事务内/事务外两个版本。
现实类比：安检插桩：每个乘客过安检门（内存访问）都要被机器扫一遍（barrier 函数）；同一乘客平时走普通通道、安检时走专用通道——两条通道是同一人的两个版本。
图示：

atomic { a.x = t1; a.y = t2; if (a.z == 0) { a.x = 0; a.z = t3; } }

    ↓ 编译器插桩（软件 barrier）

tmTxnBegin();
tmWr(&a.x, t1);
tmWr(&a.y, t2);
if (tmRd(&a.z) != 0) { tmWr(&a.x, 0); tmWr(&a.z, t3); }
tmTxnCommit();

3. Transaction Descriptor / Transaction Record（事务描述符 / 事务记录）

定义：STM 的两类核心数据结构：
- Transaction descriptor（每线程一个）：记录事务状态，用于冲突检测、提交、中止；包含读集、写集、undo log 或 write buffer。
- Transaction record（每个数据项一个）：一个指针大小的记录，守护共享数据的事务状态；处于 shared 状态时用版本号或共享读锁（允许多个读者）；处于 exclusive 状态时用指向属主事务的写锁。幻灯片特别注明：这与硬件 cache coherence 的工作方式相同。
现实类比：descriptor 像每个人的”办事档案”（办到哪一步、碰过哪些材料）；record 像每份文件上的”借阅状态牌”：多人可同时”只读”（shared），一旦有人要”独占修改”（exclusive）就挂牌写明是谁。

4. 冲突检测粒度（Object / Word / Cache-Line）与 False Conflict（假冲突）

定义：以多大的数据单位做冲突检测：
- Object 粒度：映射开销低、暴露优化机会，但产生假冲突（false conflict）——两个事务碰同一对象的不同字段也被判冲突（例如 Txn1 写 a.x、a.y，Txn2 读 a.z，对象级检测认为它们冲突）。
- Element/word（字段）粒度：减少假冲突、提高并发，但时间和空间开销都增加。
- Cache-line 粒度：与硬件 TM 天然匹配、降低事务记录的存储开销，但程序员和编译器难以分析。
- 混合策略：按类型混搭（例如数组用元素级、非数组用对象级）。
现实类比：宿舍卫生检查按”房间”（object）还是按”床位”（word）评分：按房间查，一个人乱就拖累全屋（假冲突）；按床位查更精细但检查成本高。
图例：

Txn1: a.x = …; a.y = …      Txn2: … = a.z …
对象级检测：两者都碰对象 a → 判冲突（假冲突！x/y 与 z 无关）
字段级检测：x,y 与 z 不同字段 → 无冲突，可并行

5. 基于时间戳的 STM 版本跟踪（McRT STM 风格）

定义：以 Intel McRT STM 为例（eager versioning + optimistic reads + pessimistic writes）：
- Global timestamp（全局时间戳）：每次写事务提交时递增。
- Local timestamp（每事务时间戳）：该事务上次验证时读到的全局时间戳值。
- 32-bit transaction record：最低位（LS bit）：0 表示被写者锁定，1 表示未锁定；高位（MS bits）：未锁定时存”最近一次提交的时间戳（版本号）”，锁定时存”属主事务指针”。
现实类比：图书馆的”版本号 + 借出牌”：书的版本号记录最后一次修订（timestamp），借出牌（lock bit）记录谁正在改；读者确认”版本号没涨且没人借出”才放心读。
不变量（验证条件）：数据未被锁定且数据版本 ≤ 本地时间戳 → 说明”我读到的数据没有被更新提交过”，可以安全使用。

6. Strong vs. Weak Atomicity（强原子性 vs. 弱原子性）

定义：STM 面临的内存模型问题：strong atomicity 要求即使是非事务代码访问共享数据，也必须与事务代码保持原子语义（即非事务访问也要参与冲突检测）；weak atomicity 只保证事务之间的原子性，非事务代码可以”绕过”检测。在纯软件中提供 strong atomicity 代价高昂——这是幻灯片列出的 STM 挑战之一，也是推动硬件支持（HTM）的重要动机。
现实类比：strong 像”所有车（无论是不是校车）都要遵守校车停靠规则”；weak 像”只有校车之间互相避让，普通车可以随便穿行”。

7. HTM：缓存中的版本管理（R/W 位元）

定义：硬件事务内存把数据版本管理放进 cache：要么把 write buffer（lazy）缓存在 cache，要么把 undo log（eager）缓存在 cache，并给 cache line 增加元数据位跟踪事务读集/写集：R 位（load 时置位，标记读集）、W 位（store 时置位，标记写集）。R/W 位可以按 word 或 cache-line 粒度设置，在 commit/abort 时批量清零（gang-clear）。注意：eager 版本策略下，每次写还需要第二次 cache 写来记录 undo log。
现实类比：用便利贴（R/W 位）贴在书架格子上记录”这本书我正在看/正在改”，结账（commit）或放弃（abort）时把整片便利贴一次性撕掉。
图示：

  ┌─────┬─────┬─────┬──────────────────────────┐
  │ MESI│  R  │  W  │   Line Data（如 64 字节） │
  └─────┴─────┴─────┴──────────────────────────┘
   coherence  读集  写集
   状态位     标记  标记

8. HTM：基于 coherence 协议的冲突检测

定义：coherence 请求检查 R/W 位来检测冲突（幻灯片原文）：
- 观察到对 W-word 的 shared 请求 → read-write 冲突（别人要读我写的字）；
- 观察到对 R-word 的 exclusive（写意图）请求 → write-read 冲突（别人要写我读的字）；
- 观察到对 W-word 的 exclusive 请求 → write-write 冲突（别人也要写我写的字）。
该机制对 snooping 与 directory 两种 coherence 协议都适用。
现实类比：教室里的”占位牌”系统：别人来借阅（shared 请求）发现你正在写（W 位）——冲突；别人要划掉（exclusive 请求）你正在读（R 位）的笔记——冲突；两人都要在同一页上写（W 位）——冲突。

9. Register Checkpoint（寄存器检查点）

定义：事务 begin 时必须保存处理器寄存器状态（register checkpoint），以便 abort 时恢复执行上下文（寄存器、状态等），配合缓存中写集的失效完成”回到事务起点”。这是 HTM 的 CPU 侧改动之一（许多 CPU 本身已具备该能力）；CPU 侧还需 TM state registers（记录事务状态、abort handler 指针等）。
现实类比：游戏存档：开始打 BOSS（事务）前先存档；打不过（abort）就读档重来，装备和血量回到开打前。

10. TCC（Transactional Coherence and Consistency）

定义：Stanford 提出的激进方案：把 TM 当作一致性机制本身——所有事务、所有时间（all transactions all the time），每个处理器上每个内存操作都在事务中；成功提交的事务更新内存与系统中所有 cache。TCC 的假设：lazy + optimistic；每个执行步（execution step）在所有处理器上至多一个 commit；当一个事务导致另一个事务 abort 重执行时，允许前者的 commit 与后者的 begin 重叠，以最小化执行步数。
现实类比：把整台机器当成一个”记账本共享会话”：谁要改账本都得先声明”我要改这几页”（事务），改完一次性誊写（commit）并通知所有人；撞页（冲突）的就得重写。

11. Intel RTM（Restricted Transactional Memory，受限事务内存）

定义：Intel Haswell 引入的硬件事务内存指令集：xbegin（参数为 abort 时的回退地址 fallback address，例如回退到带自旋锁的代码路径）、xend（提交）、xabort（显式中止）。实现上在 L1 cache 跟踪读集与写集，处理器保证事务内所有内存操作原子提交。但处理器可能因很多原因自动 abort（例如读集/写集所在 cache line 被逐出就会 abort），且实现不保证进展（所以才需要 fallback 地址）。Intel 优化手册第 12 章给出提高事务不 abort 概率的指南。
现实类比：用便利贴记账（L1 里的 R/W 位）；便利贴被风吹掉（cache line 逐出）就得整笔重来——所以重要交易（高冲突、大读集）不要用便利贴，直接用正式账本（fallback 锁路径）。

12. 并行 + 硬件特化（Parallelism + Hardware Specialization）与课程核心议题

定义：课程收尾的核心论断（幻灯片原话）：在可预见的未来，获得更高性能计算硬件的主要途径 = 增加并行度 + 硬件特化（hardware specialization）的结合。证据就是当代芯片：NVIDIA GPU（单个 SMM core：32-wide SIMD、每 SMM 2048 个 CUDA/thread、Tensor Cores）、Apple A11（异构 SoC：多核 CPU + 多核 GPU + 媒体 ASIC + AI 单元）、Intel Core i7（CPU + 集成 GPU 与媒体）、FPGA（可重构逻辑）、Google TPU 与 AWS Trainium（AI 加速器）。
现实类比：赛道升级不是靠把一辆车改到极限（单核频率），而是”多车并行（并行度）+ 每种赛道配专用车（特化）”。
课程反复强调的四大议题：识别并行性（或识别依赖）；高效调度任务（① 负载均衡 ② 克服通信约束：带宽限制、延迟、同步）；利用数据/计算局部性 = 高效管理状态。这些议题在异构移动 SoC、单芯片多核 CPU、多核 GPU、CPU+GPU、机器集群、AI 加速器等各种规模与场景下反复出现。

二、代码示例与详细解说（本讲重点）

示例 1：STM 展开——`atomic { obj.f1 = 42; }` 需要哪几步？（C 伪代码）

// 给定：乐观读、悲观写、eager 版本策略的 STM
// 问：实现 atomic { obj.f1 = 42; } 需要哪些步骤？

atomic {
    obj.f1 = 42;
}

// 答（幻灯片给出）：
TxDescriptor* tx = GetTxDescriptor();      // 1. 取本线程的事务描述符
OpenForWriteTx(tx, obj);                   // 2. 悲观写：验证数据版本、加写锁、加入写集
                                          //    （若被他人锁定/版本过期 → 处理冲突/中止）
LogForUndoIntTx(tx, obj, offset);          // 3. eager 版本：把旧值记入 undo log
obj.f1 = 42;                               // 4. 就地写入（eager：写内存立即生效）
// 事务结束处还有 commit：递增全局时间戳、释放写锁并置新版本号

【代码做了什么？】

一个看似普通的单字段写，在 eager + pessimistic-write STM 下被展开为四步：取描述符 → 打开写（验证 + 加锁 + 记写集）→ 记 undo → 真正写。若中途 abort，undo log 把 obj.f1 恢复原值。

【并行机制解说】

对应概念：STM barrier（概念 2）、事务描述符/记录（概念 3）、时间戳版本跟踪（概念 5）。注意”悲观写”意味着写之前必须确保数据未锁定且版本不旧于本地时间戳——写冲突在发生前就被拦截；而”乐观读”意味着读不立即验证，把验证推迟到 read-set validation / commit 阶段。这套组合正是 McRT STM 的取舍：写冲突稀有时开销小、读多写少时读路径轻快。

示例 2：HTM 事务——Intel RTM 风格 `xbegin`/`xend` 与 fallback（C + 伪指令）

#include <immintrin.h>   // Intel RTM intrinsics: _xbegin/_xend/_xabort

void update(SharedState* s) {
    // 尝试硬件事务
    unsigned status = _xbegin();          // 相当于 xbegin fallback_addr
    if (status == _XBEGIN_STARTED) {
        // ---- 事务体：普通代码，硬件在 L1 cache 维护读集/写集 ----
        s->x += 1;
        s->y = s->x * 2;
        _xend();                          // 提交：所有写原子生效
        return;
    }
    // ---- abort 路径（fallback）：用自旋锁重做（幻灯片建议的典型回退） ----
    // 注：事务可能因冲突、cache line 逐出、中断等任何原因 abort；
    //      RTM 不保证进展，fallback 必须存在
    spinlock_acquire(&s->lock);
    s->x += 1;
    s->y = s->x * 2;
    spinlock_release(&s->lock);
}

【代码做了什么？】

_xbegin() 返回 _XBEGIN_STARTED 表示事务已开始；事务体内是普通读写；_xend() 提交。任何 abort 都会让 _xbegin() 返回一个非 STARTED 的状态码（区分冲突、逐出、显式 _xabort 等），执行流落到 fallback 分支。
fallback 分支用一把自旋锁把同样的操作以互斥方式重做——这是幻灯片明说的典型用法（”fallback to code-path with a spin-lock”）。

【并行机制解说】

对应概念：HTM 的缓存版本管理（概念 7）、coherence 冲突检测（概念 8）、register checkpoint（概念 9）、Intel RTM（概念 11）。硬件做的事：begin 时取寄存器检查点；每次 load 置 R 位、store 置 W 位；其他核的 coherence 请求命中 R/W 位即触发 abort（见概念 8 的三种冲突）；commit 时”gang-clear”R/W 位、把写集变成有效脏数据。幻灯片强调：处理器可能因很多原因自动 abort（例如读集/写集所在 cache line 被逐出），且 RTM 不保证进展——所以 fallback 地址不是可选项而是必需品。
幻灯片给出的 HTM 性能数据：比 STM 快 2x–7x；单线程时离顺序执行只差 10% 以内；随处理器数高效扩展——因为冲突检测与版本管理全部由硬件流水线完成，无软件 barrier 开销。

示例 3：TM vs 锁——从”程序员的视角”对比（伪代码）

// 视角 1：粗粒度锁（简单但串行化）
Object get_sync(Map m, Key k) {
    synchronized (m) { return m.get(k); }   // 整个 map 一把锁：安全、易写、扩展性差
}
// 视角 2：细粒度锁（并发好但难写、无需同步也付锁开销）
Object get_fine(Map m, Key k) {
    lock(m.bucket[hash(k)].lock);           // 每 bucket 一把锁
    return m.bucket[hash(k)].get(k);
    unlock(m.bucket[hash(k)].lock);
}
// 视角 3：事务（声明式：系统保证原子性）
Object get_tx(Map m, Key k) {
    atomic { return m.get(k); }             // 系统实现原子性；读-读并发自动获得
}

三种实现的取舍（幻灯片综合）：
  正确性成本：synchronized 最易写；细粒度最难（锁顺序、死锁）；
              atomic 与 synchronized 一样易写（声明式）
  并发潜力：synchronized 最低；细粒度与 atomic 高（读-读天然并发）
  开销特征：细粒度"即使不需要同步也付锁开销"；atomic 乐观执行，无冲突时几乎零开销
  可移植性：锁方案在 4 核最优未必在 64 核最优（performance portability）

【代码做了什么？】

三个版本都实现线程安全的 HashMap.get。事务版本只是把 m.get(k) 包进 atomic { }，语义上系统保证原子性；性能取决于工作负载与 atomic 的实现（幻灯片原话，第 17 讲已述）。

【并行机制解说】

对应概念：TM 的承诺（第 17 讲）+ 本讲的设计空间（概念 1）。幻灯片数据：硬件 TM（TCC）在 balanced tree 与 HashMap 上都优于 coarse locks 与 fine locks。但性能不是唯一的账——生产力论点（幻灯片原话）：系统级事务支持能以开发时间的 10% 获得专家级细粒度锁编程约 90% 的收益（第 18 讲版本的数字）。这正是”事务”作为第 17 讲所定义的更高层抽象存在的意义：把同步的复杂度从程序员转移到系统。

示例 4：TCC trace——把 TM 当一致性机制（表格演示，据幻灯片整理）

处理器 P1          P2            P3
─────────────────────────────────────────────
Begin T1          Begin T2       Begin T4
Read  A (A:0)     Read  A (A:0)  Read  E (E:0)
Write A ← 1       Write E ← 3    Write B ← 6
Write C ← 2                      Write C ← 7
Read  D (D:0)                    Read  F (F:0)
Commit T1  →      Commit T2  →   Commit T4  →
（随后 P1 开始 T3）  Read E (E:3)  （随后 Commit T3）
Write C ← 5
Read  A (A:1)
Write E ← 6
Commit T3
─────────────────────────────────────────────
幻灯片 trace 中提交顺序：T2 → T1 → T4 → T3
读集/写集随执行逐步累积；每步至多一个 commit；
若某事务因其他事务 commit 而 abort，其重执行可与提交重叠，以最小化执行步数

【代码做了什么？】

这是幻灯片第 44–48 页的 TCC 执行 trace 的简化整理：三个处理器并发执行事务，表格记录每个事务逐步累积的读集（如 A:0 表示读到 A 的旧值 0）与写集（如 A:1 表示把 A 写成 1）。提交按某个串行顺序发生（T2 → T1 → T4 → T3），读到的值反映之前提交者的结果（T3 读 A 得到 1，正是 T1 提交的值）。

【并行机制解说】

对应概念：TCC（概念 10）+ HTM（概念 7/8）。TCC 把事务提升为系统唯一的一致性机制：所有内存操作都在事务中，成功提交的事务更新内存与全部 cache。幻灯片列出的假设决定其行为：lazy + optimistic；每执行步至多一个 commit；被 abort 的事务重执行可与提交方 commit 重叠。这个例子把”读集/写集跟踪 + 串行提交顺序 + 提交可见性”完整串起来，是理解 HTM 如何兑现第 17 讲三条语义（atomicity/isolation/serializability）的最佳直观样例。

三、关键要点

TM 设计空间已”人满为患”但无定论：eager/lazy × pessimistic/optimistic × object/word/cache-line 的组合几乎都被实现过（TL2、OSTM、Intel STM、TCC、LTM、VTM、LogTM），但最优设计仍是开放问题，且 HW、SW、hybrid 答案可能不同。
STM 的代价在 barrier 与内存模型：软件插桩带来 2–8x 每线程开销（单线程即比顺序执行慢 1.8–5.6x，大头在读 barrier 与 commit），还需要函数克隆，且纯软件提供 strong atomicity 成本高昂——这些正是硬件支持的动机。编译器优化（分解 barrier 暴露冗余）能把单线程开销压到无并发控制的 40% 以内、锁方案的 30% 以内。
HTM 把版本管理与冲突检测”搬进” coherence 协议：cache line 的 R/W 位记录读集/写集，shared/exclusive 请求命中 R/W 位即检测出 R-W / W-R / W-W 冲突；R/W 位 commit/abort 时批量清零；配合寄存器检查点完成回滚。性能：比 STM 快 2–7x，单线程距顺序执行 10% 以内。
HTM 不是银弹：Intel RTM 不保证进展（cache line 逐出等就会 abort），必须提供 fallback；TCC 这类”全事务”系统依赖 lazy+optimistic 与每步单 commit 的假设。事务是”提高同步抽象层次”的一种工具，不是取代一切锁的万能方案。
课程主线回顾：性能来自并行度 + 硬件特化；获得性能的关键能力是识别并行/依赖、高效调度（负载均衡、克服带宽/延迟/同步约束）、利用局部性管理状态——这些思想在 CPU、GPU、SoC、集群、AI 加速器上以不同形态反复出现；而”现代软件相对硬件峰值能力惊人地低效”，理解并行机器的原理是挖掘这份性能的前提。

四、常见陷阱与注意事项

把 HTM 当”免费的原子性”：RTM 事务可能因 cache line 逐出、中断、过大读写集等原因无冲突地 abort，且硬件不保证进展——没有 fallback（如自旋锁路径）的程序会挂死或反复失败；Intel 优化手册第 12 章的指南（控制事务大小、避免逐出等）是提高成功率的必修课。
忽略 STM 的常数开销：软件 barrier 使单线程就比顺序执行慢近 2–6 倍，读 barrier 与 commit 是主要开销源（大多数应用读多写少）；”事务免费”是幻觉，收益必须与冲突率、事务大小一起评估。
以为对象级检测就够细：对象/粗粒度会造成假冲突（Txn1 写 a.x、Txn2 读 a.z 被误判冲突），反而损失并发；但 word 级检测又抬高时间/空间开销——粒度选择本身就是工程权衡，幻灯片明说 cache-line 粒度”对程序员与编译器都难分析”。
课程层面的老毛病：只优化串行部分忽略 Amdahl 定律、只盯计算峰值忽略带宽与延迟约束、把负载均衡想当然（workload imbalance 静默拖垮扩展性）、在弱一致性/弱原子性模型上写想当然的同步代码——这些在第 16–18 讲的多线程与事务语境下依然成立。
学完就停：幻灯片强调课程结论——未来性能靠”并行 + 特化”；如果只记住 API 不掌握”识别并行、调度、通信、局部性”的分析框架，面对新的并行硬件（下一代的 GPU、加速器、异构 SoC）会无从下手。

五、思考题（带答案）（本讲为课程整体反思题）

Q1：课程结尾说”现代软件相对硬件峰值能力惊人地低效，大量性能被留在桌上”。结合课程内容，请列举至少三个”性能被留下”的典型原因，并说明对应的课程知识点。 A1：① 并行度没被利用：程序存在未识别的依赖/串行瓶颈（Amdahl 定律，识别并行性/依赖）；② 调度不当：任务粒度过粗导致负载不均衡、或通信/同步开销吞掉并行收益（work distribution、work stealing、通信约束：带宽限制与延迟）；③ 局部性差：数据访问模式导致 cache miss、内存带宽浪费（数据/计算局部性 = 高效管理状态，例如分块、向量化、减少数据移动）。机器越复杂（多核、异构、加速器），这份”被留下”的性能越大——这正是并行系统原理知识的价值所在。

Q2：请用课程框架（并行性识别、调度、通信、局部性）快速评估一个”新”系统：例如一个 64 核 CPU + 4 个 Tensor Core 加速器的异构芯片上跑 LLM 推理。你会关注哪些问题？ A2：并行性识别：哪些算子是 data-parallel 可向量化/可上 Tensor Core（矩阵乘），哪些是串行依赖（如 attention 的 softmax 归约、KV cache 顺序更新）；调度：任务如何切分到核与加速器、如何避免负载不均衡与同步瓶颈（每层一次 kernel launch 还是融合）；通信：权重与激活的带宽需求 vs 芯片互连带宽、数据移动次数（算子融合减少中间张量读写）、延迟隐藏（流水线/多 batch）；局部性：权重驻留（cache/片上内存复用）、K/V 复用、batch 内复用。这套”先看并行、再看调度、再看通信、再看局部性”的顺序正是课程每讲的通用分析套路。

Q3：学完 CS149 后，如果想继续深入，幻灯片推荐的三门课分别侧重什么？结合你自己的兴趣，你会选哪条路？ A3：① CS 217（Hardware Accelerators for Machine Learning，冬季，Kunle 授课）：面向 ML 的硬件加速器设计——延续课程”硬件特化”主题，从芯片/架构角度理解 TPU、Trainium 这类加速器；② CS/EE 282（Computer Systems Architecture）：计算机系统架构，深入处理器微架构、内存层次、一致性协议（本讲 HTM 的 coherence 冲突检测正是在这类课程里继续深入）；③ CS 348K（Visual Computing Systems，春季，Kayvon 授课）：面向图像/视频的高性能软硬件系统设计（光线追踪、视频分析、手机相机处理、NeRF/AI 图形、快速数据标注等）——把课程的”并行+特化+局部性”方法论应用到图形与视觉系统。选课取决于兴趣方向：硬件/架构选 217/282，系统与图形选 348K；也可以继续了解 Kayvon 实验室的研究机会（LLM agent 效率优化、并行调度编译器抽象、1M fps 世界模拟引擎、虚拟运动员模拟、AI play tester、CS149 assistant agent 等）。

Share on

Bluesky Facebook LinkedIn Mastodon X (formerly Twitter)

Runguo Li