第 18 章 GPU 与异构计算 on Go 语言原本

18.1 跨越 FFI 边界

Mon, 01 Jan 0001 00:00:00 +0000

18.1 跨越 FFI 边界

15.6已经把 cgo 这座桥拆开看过了：一次从 Go 到 C 的调用要切到 g0 系统栈、按 C 的 ABI 重摆参数、entersyscall 让出 P、调用、再 exitsyscall 抢回一个 P，整套下来比一次 Go 调用贵上一两个数量级。那一节给出的结论很干脆：cgo 适合少量、粗粒度的调用，最忌讳放进热点循环里反复跨界。

把这条结论摆到 GPU 面前，矛盾立刻就尖锐了。GPU 编程的本质，恰恰是频繁地跨界。一次最普通的推理或渲染，CPU 这侧要做的事无非三类：把数据从主机内存拷到显存、启动一个又一个 kernel、再把结果拷回来。每一类都是一次离开 Go、进入驱动的边界穿越。一个稍有规模的神经网络有成百上千个算子，逐个朴素地启动，就是成百上千次 cgo 调用串在一条关键路径上。15.6 说「别在紧循环里跨界」，而 GPU 的工作负载天生就长在这样一个紧循环里。这一节要回答的就是：当跨界无法避免、且必须高频时，这道边界该怎么设计才不至于被通行费压垮。

18.1.1 边界的另一端：一个异步的命令世界

先看清桥的对岸站着谁。从 Go 调一个 C 库函数，对岸是一段同步执行的 C 代码，调用返回时活儿就干完了。 GPU 不是这样。CPU 这侧调用的并不是「计算本身」，而是向设备下达一条命令。

以 CUDA 为例，软件栈分了两层。底层是驱动 API（driver API，libcuda，前缀 cu），直接对应内核态驱动暴露的能力；上层是运行时 API（runtime API，libcudart，前缀 cuda），把驱动 API 包装得更易用，自动管理上下文与模块。无论走哪一层，CPU 侧的一次 cudaLaunchKernel 或 cudaMemcpyAsync 都只是把一条命令塞进一个叫流（stream）的队列，然后立即返回。真正的计算由 GPU 在自己的时间线上异步地完成。CPU 下令，GPU 干活，两者在不同的时钟上跑。

18.2 调度器与阻塞的外部调用

Mon, 01 Jan 0001 00:00:00 +0000

18.2 调度器与阻塞的外部调用

18.1 给出的药方是「异步、少同步」：把命令压进流，立即返回，只在末尾等一次。可那「末尾的一次」终归要等。cudaStreamSynchronize 会一直阻塞，直到 GPU 把整条流排空；一次同步的 cudaMemcpy,一次没走异步路径的驱动调用，都会让 Go 这侧的线程实打实地停在 C 里。本节要问的就是：当一次跨界真的会长时间阻塞时，第 9 章那套调度机器会怎样反应？它会不会被一个卡在 GPU 上的调用拖垮？

答案要从两个方向看。Go 阻塞在 C 里是一个方向，C 反过来回调 Go 是另一个方向，调度器在这两个方向上各有一套应对。

18.2.1 一次阻塞的跨界，调度器看见的是什么

先回忆第 9 章的图景：调度器在 M（系统线程）、P（逻辑处理器，数量受 GOMAXPROCS 限制）、 G（goroutine）三者上编排并发，一个 M 必须先绑定一个 P 才能运行 Go 代码。

15.6 已经讲过，cgocall 在跨界前会调用 entersyscall。这一步的意义此刻变得关键： 在调度器的记账里，一次 cgo 调用和一次系统调用是同一回事。M 被标记为「正处于系统调用中」，它承载的 goroutine 转入 _Gsyscall 状态。这里有一个随版本演进的实现细节值得一提：早先的运行时还专门给 P 设过一个 _Psyscall 状态来表示「这个 P 正陷在系统调用里」，但 Go 1.26 起这个 P 状态已退役（源码里留作 _Psyscall_unused），改为直接看 goroutine 的状态来判断一个 P 是否在系统调用中。这次精简并非无关紧要，它顺带把每次 cgo 跨界的固定开销削减了约三成,正是 18.1.2 那「第一笔成本」被运行时自己磨薄的一例。从这一刻起到 C 调用返回，有一条铁律：

18.3 显存与垃圾回收的分界

Mon, 01 Jan 0001 00:00:00 +0000

18.3 显存与垃圾回收的分界

15.6 讲过 cgo 的指针规则：Go 的对象不归 C 管， GC 随时可能搬走或回收它，所以 C 不得在调用返回后还持有一个未钉住的 Go 指针。那是从「Go 与 C 两块内存」的二元世界推出来的。GPU 把这张地图复杂化了：现在至少有四种内存，分属不同的管辖，遵守不同的规矩。这一节要先把这张地图画清楚，再看垃圾回收器与它们各自的分界划在哪里，以及哪一条分界最容易在异步传输里被踩穿。

18.3.1 一张内存地图

一个用 Go 驱动 GPU 的程序，运行时面对的内存大致分四块：

flowchart TB
 subgraph host["主机内存（CPU 可寻址）"]
 go["Go 堆<br/>GC 管理：可移动、可回收、被扫描"]
 c["C 堆 / malloc<br/>手动管理：GC 不可见"]
 pinned["页锁定内存 cudaHostAlloc<br/>不可换出，供 DMA 高速传输"]
 end
 subgraph device["设备内存（GPU 上，CPU 不可寻址）"]
 dev["显存 cudaMalloc<br/>GC 完全看不见，手动 cudaFree"]
 end
 go -. "cudaMemcpy" .-> dev
 pinned -. "cudaMemcpyAsync（快）" .-> dev

四块里，只有第一块 Go 堆归 GC 管，第 12、13 章那套分配与回收、那套可达性扫描，作用范围就到这里为止。后三块对 GC 而言是「境外」：C 堆是手动 malloc/free 的，页锁定内存由 CUDA 分配，而显存根本不在 CPU 的地址空间里,CPU 连解引用它都做不到。理解这一节的全部诀窍，就是时刻分清一个指针到底落在哪一块。

18.4 异步编程模型

Mon, 01 Jan 0001 00:00:00 +0000

18.4 异步编程模型

前三节都在讲 FFI 边界上的「成本」：过桥要快（18.1）、过桥会占住线程（18.2）、桥上的内存归谁管（18.3）。这一节换一个角度，回到并发模型本身。Go 的并发是 goroutine 与通道，GPU 的并发是另一套东西，CPU 自己还藏着第三套。把这三套并行摆清楚、看明白它们怎么对接，是这一章的收尾，也是理解「何时该把活儿推过边界、何时压根不必」的关键。

18.4.1 三种并行，别混为一谈

「并发」（concurrency）与「并行」（parallelism）的区分，第 9 章借 Rob Pike 的话讲过：并发是 把程序拆成可独立推进的部分的结构，并行是同时执行的事实。带着这把尺子，眼前这三套各占什么位置就清楚了。

goroutine 并发。 Go 的看家本领，M:N 的任务级并发。每个 goroutine 是一段独立的控制流，廉价、可阻塞、靠通道通信。它回答的是「如何把程序组织成许多并发的任务」。
SIMT（GPU）。 Single Instruction, Multiple Thread。一次 kernel 启动铺开一张由成千上万个线程组成的网格，它们跑同一段程序、各自处理一个数据元素，硬件以 warp（NVIDIA 上 32 个线程一组）为单位近乎锁步地推进。它回答的是「如何让海量数据元素被同一段计算并行碾过」。编程模型是：为单个元素写好 kernel，然后启动一整张网格。
SIMD（CPU）。 Single Instruction, Multiple Data。在一个 CPU 核内，一条指令同时作用于一个向量寄存器里的多个数据通道（4、8、16 路）。它是 CPU 自带的数据级并行，不需要 GPU、不跨任何边界。

这三者是正交的轴，可以叠加：一个 Go 程序完全可以用 goroutine 并发地处理多个请求，在每个请求的 CPU 内循环里用 SIMD 向量化，再把最重的矩阵乘用 SIMT 推给 GPU。把它们混为一谈（比如「一个 GPU 线程就像一个 goroutine」）会从一开始就把设计带偏:goroutine 是为可阻塞的任务生的，GPU 线程是为无分支的密集算术生的，两者的设计假设南辕北辙。