阅读视图

发现新文章,点击刷新页面。
🔲 ☆

GPU 计算的起源

本文永久链接 – https://tonybai.com/2026/04/17/the-origins-of-gpu-computing

大家好,我是Tony Bai。

在今天的人工智能时代,GPU 已成为数据中心的核心算力引擎,但它的崛起并非一夜之间的奇迹。ACM通讯文章《The Origins of GPU Computing》回溯了 GPU 计算的三十年发展史,揭示了从并行计算、图形系统到流处理等关键技术如何在政府资助的学术研究中逐步成熟,并最终汇聚成推动深度学习革命的基础设施。文章不仅梳理了技术脉络,也展示了学界与产业之间如何通过人才与思想的流动,共同塑造了现代 GPU 计算的格局。

本文是这篇文章的译文,供大家学习参考(格式有调整,更适合公众号阅读)。


政府资助的并行计算、流处理、实时着色语言和可编程图形处理单元(GPU)的学术研究直接推动了 GPU 计算的发展。GPU 被广泛应用于现代数据中心,并促成了当前的人工智能(AI)革命。生产 GPU 的英伟达(Nvidia)现已成为世界上最有价值的公司。这种计算变革及其产生的经济价值,得益于超过 30 年的政府资助研究。政府资助不仅有助于发展许多关键的技术创新,还培养了大量将这些技术带入行业的学生。

本文追溯了 GPU 计算的起源。我们首先描述了 GPU 计算所构建的技术(并行计算、并行图形系统、可编程着色器(shaders)和流处理)的发展,然后详细介绍了这些技术是如何转移到英伟达和其他公司,并最终应用于现代机器学习的。

赋能技术

GPU 计算建立在并行计算、并行图形系统和流处理的早期工作基础上。这些技术是通过超过 30 年的政府资助学术研究发展而来的。

并行计算

当你学习计算时,你了解到的是中央处理器(CPU)按顺序执行一系列指令。

实际上,芯片包含数十亿个并行切换并由导线连接的晶体管。开关和导线是物理计算机的基本构建块,它们同时运行。

此外,晶体管切换消耗的能量很少,而沿导线的通信消耗的能量要多得多。

通信需要功率来将信号从一点发送到另一点;功率随着距离的增加而增加,如果是在芯片之间进行信号传输,功率消耗将非常巨大。

虽然顺序计算机可能比并行计算机更容易理解,但顺序计算机必须通过同时切换的晶体管和同时传输信息的导线来实现。顺序计算机使用许多晶体管并行计算结果,然后仔细地以与顺序执行一致的方式组装这些结果。

创建这种执行是顺序的“幻觉”,在功率和性能上都是低效的。随着可用晶体管数量的增加,这种低效性也随之增加。在现代半导体技术中构建计算机的自然方式是设计并行计算机。GPU 比 CPU 更高效,因为它们是大规模并行计算机。

GPU 计算建立在并行计算的早期工作之上。与所有并行计算机一样,在 GPU 上运行的并行任务或线程必须相互同步和通信。

线程需要通信来使用由另一个线程产生的数据。同步是必要的,以在数据可用时发出信号,确保消耗的是正确的值。

并行计算、同步和通信的许多基础知识是由政府资助的学术研究开发的。由加州理工学院 Chuck Seitz 领导的 DARPA 资助的“宇宙立方”(Cosmic Cube)项目发展了并行计算的许多基础知识。在该项目上开发的硬件是英特尔 iPSC、Delta 和 Paragon 机器的蓝图,以及几台早期的能源部 ASCI 机器。“Cosmic-C”编程语言引入了异步消息传递和集合通信,后来以消息传递接口(MPI)的形式成为编程大型并行机器的标准。

麻省理工学院(MIT)的 DARPA 资助的 J-Machine 和 M-Machine 项目开发了用于通信和同步的低开销机制,以及现代互连网络的许多关键方面。这些机制使得并行性可以在非常细的粒度上被利用,最少只需 10 或 20 条指令即可作为一个可调度的工作单元。J-Machine 的许多特性被 Cray T3D 和 T3E 计算机直接采用。

并行计算有着超越这一特定历史分支的丰富历史。由于篇幅有限,我们无法进行完整的综述。Culler 等人的文章提供了一个很好的回顾。

GPU 计算与所有高性能计算一样,深受这一遗产的影响。它使用 MPI 进行节点间的通信,使用互连网络连接这些节点,并且在此研究过程中开发的许多通信和同步机制被用于协调并行计算。

并行图形系统

虽然不如传统的并行计算和超级计算机广为人知,但并行图形和成像计算机有着悠久的历史。

处理和生成图像需要巨大的计算量。例如,如果一台每秒处理一百万条指令的计算机(1MIPS)对百万像素图像的每个像素应用一次算术运算,计算机需要一秒钟来处理一张图像。

渲染电影和游戏中的 3D 虚拟世界比图像处理每像素需要的计算量大几个数量级。例如,为现代电影生成的图像每个像素需要大约十亿次浮点运算。因此,为了在实践中有用,图形和成像需要高性能的并行超级计算机。这些计算机在大规模数据集合上并行计算。

一个早期的 DARPA 资助研究项目是吉姆·克拉克(Jim Clark)在斯坦福大学领导的几何引擎(Geometry Engine)。

几何引擎促成了硅谷图形公司(Silicon Graphics)的成立,该公司率先开发了 3D 图形工作站。SGI 硬件架构和 OpenGL 软件库定义了现代 GPU 架构。

另一个值得注意的政府资助研究项目是亨利·福克斯(Henry Fuchs)及其合作者在北卡罗来纳大学领导的 Pixel Planes 系列高性能图形系统。事实上,Pixel Planes 5 是一台相当通用的单指令多数据(SIMD)计算机,它在 128 x 128 图像上运行并行计算。其他早期并行图形和图像计算机的例子包括 NASA 的大规模并行处理器(MPP)、Ikonas 图形系统和 Pixar 图像计算机。

早期 GPU 实现了类似于早期 SGI 工作站的固定功能图形流水线。当整个 OpenGL 图形流水线可以在单个芯片上实现时,英伟达引入了“GPU”一词。1999 年推出的英伟达 Geforce 256 由 1700 万个晶体管组成,是第一款商用 GPU。

在此之前,在皮克斯(Pixar)工作期间,Hanrahan 开发了 RenderMan,这是一个生成照片级逼真图像的系统。该系统彻底改变了电影行业,因为它能够生成可以与相机拍摄的实景无缝结合的图像。RenderMan 的一个关键组件是着色语言,它使用户能够扩展系统以模拟复杂的材质和光照。

虽然最初的 GPU 实现了固定功能流水线,但它们是由可编程组件构成的。不幸的是,这些处理单元因系统而异,因代而异。需要的是一种可移植的编程模型。由于 GPU 的主要应用是电脑游戏,因此将 RenderMan 着色语言适配到 GPU,以便游戏开发者可以创造新的光照和着色效果似乎是自然而然的。

在斯坦福大学的一个 DARPA 资助项目下,为当时的 GPU 设计并实现了一种实时着色语言(RTSL)。着色语言程序现在被称为着色器(shaders)。博士后学者 Bill Mark 领导了斯坦福 RTSL 的设计,后来加入了英伟达。他与另一位前斯坦福研究生 Kurt Akeley 一起增强了该技术,并创建了 Cg 着色语言。Cg 导致了微软 HLSL 和 OpenGL GLSL 的开发。

人们很快意识到,这些早期的着色语言足够灵活,可以实现科学计算中的许多算法。研究人员采用了诸如矩阵乘法、线性求解器、流体动力学求解器和分子动力学等算法在着色器上运行。这导致了 GPGPU(通用 GPU)计算运动的兴起。

流处理

DARPA 和 DOE 在斯坦福大学资助的关于 Imagine 流处理器和 Merrimac 流式超级计算机的工作发展了流处理,这是一种导致算术强度(计算与带宽之比)增加的并行计算形式。

如前所述,处理器消耗的大部分功率是在通信上。在芯片之间发送信号尤其耗电。芯片外通信也比芯片内通信慢得多。

流处理包含两个减少内存带宽需求的主要思想。

第一个是利用生产者-消费者局部性,使得一个阶段(生产者)将其结果转发给下一个阶段(消费者),而无需写入和读取内存。

第二个主要思想是将计算组织成称为内核(kernels)的函数。每个内核获取一个数据包,对该包执行函数,并输出另一个数据包。函数中的算术运算数量大于对内存的读写次数。这两种技术显著减少了内存访问次数,并提高了流处理架构的效率。

在流处理器中,计算被组织成产生和消耗数据流的内核。产生内核会将输出流写入流寄存器文件(SRF)。消费内核会从 SRF 读取输入,而数据无需写入或从内存中读取。通过适当的调度来匹配流的批处理大小与 SRF 的容量,这种组织使得应用程序能够维持非常高的算术强度(算术与内存带宽之比)。

一个设计和构建 Imagine 流处理器的 DARPA 资助项目于 1997 年在 MIT 启动,并于同年晚些时候转移到斯坦福大学。Imagine 是一台用于信号和图像处理工作负载的图形和媒体处理器。它由许多带有本地寄存器文件的并行算术单元、一个中央流寄存器文件和一个内存系统组成。内核从流寄存器文件读取流,通过本地寄存器文件传递中间结果,并将输出流写回流寄存器文件,供下一个内核读取。

Stream-C 编程语言被开发用于编程 Imagine。它扩展了 C 编程语言,增加了描述内核和流的构造。开发了众多的图形、信号处理和图像处理应用程序来调整和评估该架构。它在纹理映射光栅图形上的性能与当时的固定功能 GPU 相当。

在一次 DARPA 主要研究人员会议上,本文作者意识到这项技术可以应用于高性能计算,并构思了 Merrimac 项目。斯坦福 DOE ASCI 中心的计算机科学(CS)部分被重定向以追求这种高性能计算方法。该中心的年度报告提供了流处理发展史的详实记录。

Merrimac 架构被定义为将流处理适配到科学应用。与 Imagine 相比,主要变化是增加了科学计算所需的数据类型(如 FP64),将架构扩展到通过互连网络连接的多个节点以处理大规模问题,并增加了许多弹性特征,以支持在具有合理故障率的情况下进行大规模计算。

Stream-C 编程语言演变成了 Brook。Brook 背后的关键思想是将流编程的想法与更传统的数据并行计算合并。内核函数成为保持高算术强度的关键处理原语。

Brook 被适配以针对 2000 年代初的 GPU。这些 GPU 运行可编程顶点和片段着色器。着色器实现了内核,但指令数量有限且寄存器很少。常见的数据并行编程原语(如 map、reduce/scan、filter、gather 和 scatter)是通过在低级图形着色器之上构建虚拟数据并行计算机来实现的。这种抽象使得大量现有的并行算法可以在 GPU 上运行,并且早期着色器的局限性逐渐被消除。

早期利用内核执行高算术强度计算的一个很好的例子是稠密矩阵-矩阵乘法,它是现代神经网络算法的基础。在执行矩阵-矩阵乘法时,需要读取两个 n×n 矩阵并写入一个 n×n 矩阵。矩阵乘法需要 n³ 次乘加运算。因此,算术强度为 O(n)。这一事实众所周知,并导致了针对带有缓存的 CPU 进行矩阵乘法分块的有效方法。分块在 GPU 上运行时也非常有效。

斯坦福 ASCI 中心的数值科学家将几种科学代码移植到 Brook,以便在 Merrimac 模拟器上运行。这些代码包括计算流体动力学、磁流体动力学和 n 体模拟。n 体模拟是高效 GPU 应用的一个很好的例子。原子对之间的力由天体物理模拟中的引力定律给出,但非结合原子之间的相互作用由 Lennard-Jones 势(甚至更复杂的经验势)近似。这些函数需要许多算术运算。对于这些模拟,相邻原子存储在“邻居列表”中。分子动力学模拟立即成为 GPU 的主要应用。

GPU 和流处理器的一个关键特征是它们具有多种形式的硬件并行性。

每个 GPU 由许多核心组成。每个核心包含一个 SIMD 处理单元(通常为 32 宽)。

此外,每个核心都是多线程的。

回想一下,GPU 是为图形应用程序开发的,其性能取决于将纹理应用于三角形的效率。

纹理映射涉及计算三角形内每个像素片段的纹理坐标,然后使用这些坐标从图像中获取。这些纹理获取具有空间局部性,但时间局部性很小。空间局部性可以通过小型缓存来处理,但由于缺乏一致性,缓存无法处理时间局部性。

高效的纹理映射要求 GPU 隐藏这些纹理获取的延迟。早期 GPU 通过让片段请求纹理、挂起该片段的执行,并立即切换到处理另一个片段来实现这一点。这是多线程的简化版本,这意味着 GPU 需要有许多并行线程同时运行。任务总数是核心数乘以 SIMD 算术单元数(称为 warp)乘以线程数。Blackwell B200 GPU 拥有 384 个流多处理器(SMs)。每个 SM 有 64 个驻留 warp,每个 warp 有 32 个线程。因此,该 GPU 上有 786,432 个任务同时执行。

技术转移

流处理架构和编程系统通过人员流动从斯坦福转移到了英伟达。英伟达的一位架构师 John Nickolls 听说过流处理,并招募了 Bill Dally 在 2003 年为英伟达的 NV50 架构提供咨询。(NV50 于 2006 年作为 G80 发布)。流处理器的许多特性被合并到了该架构中。NV50 的“共享内存”发挥了 Imagine 和 Merrimac 中 SRF 的作用。

Ian Buck(Merrimac 项目的研究生和 Brook 的主要开发人员)于 2004 年加入英伟达。Ian 与 John Nickolls 合作将 Brook 演进为 CUDA。CUDA 合并了 Brook 和 Cg(一种图形着色语言)的最佳特性,并采纳了 Brook 程序员的反馈。关于该技术如何从斯坦福转移到英伟达的故事在一篇演示文稿中进行了描述。Mike Houston(该项目的另一位研究生)加入了 AMD,并直接使用 Brook 作为其 GPU 的编程语言。G80(NV50)和 CUDA 于 2006 年在超级计算大会上发布。

当 CUDA 于 2006 年发布时,很少有人了解并行编程,更不用说 GPU 流编程了。为了克服这一劳动力短缺,Wen-Mei Hwu 和 David Kirk 通过为教授讲授 CUDA 编程课程来推广 GPU 计算。参加这些课程的教师随后教授了成千上万的学生使用 CUDA 进行并行编程。从 Cosmic Cube、J-Machine 和 M-Machine 借来的并行计算技术既被应用于 GPU 内部(以协调多个 SM),也被应用于跨 GPU(构建多节点 GPU 系统以解决大型问题)。

赋能 AI

现代机器学习依赖于三个关键要素——海量数据集、具有许多层和权重的庞大模型,以及优化权重的计算能力。核心算法(深度神经网络、卷积网络、使用反向传播的训练和随机梯度下降)自 20 世纪 80 年代或更早以来就一直存在。大型标注数据集,例如 PASCAL 和 Imagenet,出现在 21 世纪初。最近的进展,例如将文本嵌入到向量空间中,使得自然语言深度学习成为可能。Transformers(“注意力就是你所需要的”)用带有历史记录的易于训练的神经网络取代了难以训练的循环神经网络。GPU 计算使得大规模数据集的网络训练在经济上变得可行。一旦展示了这种能力(Alexnet, GPT),AI 的能力就得到了迅速提升。AI 的快速采用为改进 GPU 计算系统提供了更大的动力。

英伟达的机器学习也得益于学术界与产业界的协同效应。2010 年,作者之一(Dally)与吴恩达(Andrew Ng)的一次早餐交谈促成了一个英伟达与斯坦福之间的联合项目,旨在 GPU 上构建深度神经网络。Bryan Catanzaro 领导了该项目的英伟达部分。在此项目中开发的软件成为了 CuDNN,它为英伟达 GPU 上的深度学习提供了一个现成的库——从而推动了深度学习的普及。

结论

GPU 计算背后的技术(已促成了现代机器学习)主要归功于 30 年的政府资助学术研究。

并行计算、并行图形系统和流处理的研究为 GPU 计算奠定了基础。在这些研究项目中培养的许多学生后来进入行业,转移了这些技术并利用其开发了创新产品。

从斯坦福流处理项目到 GPU 计算的转移非常直接,学术上的 Brook 语言演变为 CUDA,流处理器的功能被整合到 G80 GPU 中。

GPU 提供的高效、易于编程且性能极高的计算平台,通过计算着色器促成了当前的机器学习革命——提供了缺失的成分,以补充早已可用但一直缺乏计算能力的算法和数据。

资料链接:https://cacm.acm.org/federal-funding-of-academic-research/the-origins-of-gpu-computing/

关于作者

威廉·J·达利是美国加利福尼亚州圣克拉拉英伟达公司首席科学家兼高级副总裁,同时也是斯坦福大学电气工程与计算机科学的兼职教授。

帕特·汉拉汉是美国加利福尼亚州斯坦福大学电气工程与计算机科学的佳能荣休教授。


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

🔲 ☆

被嘲笑比 Python 还慢?扒开 Go 正则表达式的底层,看看它为了防范“系统猝死”付出了什么

本文永久链接 – https://tonybai.com/2026/03/17/why-is-go-regex-so-slow

大家好,我是Tony Bai。

如果有人问你:在处理纯 CPU 密集型的文本匹配时,Go 和 Python 哪个快?

相信 99% 的 Go 开发者会毫不犹豫地把票投给 Go。毕竟,一门编译型的静态语言,怎么可能输给拖着 GIL 锁的解释型脚本语言?

但现实往往比小说更魔幻。

最近,在 Reddit 的 r/golang 论坛上,一张残酷的 Benchmark 跑分图引发了整个 Go 社区的剧烈震荡。一位开发者,使用极其常见的日志解析正则表达式(提取 IP、时间、URI 等),对各大语言进行了一次横评。

结果令人大跌眼镜:同样的数据集,Rust 跑了 3.9 秒,Zig 跑了 1.3 秒,而 Go 居然跑了整整 38.1 秒!整整比第一名 Zig 慢了接近 30 倍!

如果你再去翻看 Go 官方的 Issue #26623,会看到更绝望的数据:早在2018年的一次正则基准测试中,Go 不仅被 C++ 和 Rust 碾压,甚至连 Python 3、PHP 和 Javascript 都能在正则上把 Go 按在地上摩擦。

一时间,无数 Gopher 信仰崩塌:“为什么 Go 的标准库 regexp 这么慢?”、“连简单的正则都做不好,Go 凭什么做云原生霸主?”

今天,我们就来硬核扒开 Go 语言 regexp 包的底层设计和实现。你会发现,这不是 Go 团队的技术拉跨,而是一场关于“性能、安全与工程哲学”的博弈。

原罪:你以为的慢,其实是替 CGO 负重前行

面对“为什么 Go 的正则比 Python 还慢”的灵魂拷问,Go 核心团队成员 Ian Lance Taylor 给出了第一层解释。

在 Python、PHP 甚至 Node.js 中,你以为你是在运行脚本,其实它们底层都在悄悄“作弊”。这些语言的正则表达式引擎,几乎全部是用高度优化的 C 语言库(主要是 PCRE,Perl Compatible Regular Expressions)编写的。

当你在 Python 里调用 re.match() 时,它瞬间就穿透到了 C 语言的底层,享受着现代 CPU 指令集的极致加速。

那 Go 为什么不用 C?因为 Go 是一门有着“极度洁癖”的语言。

如果 Go 的标准库引入了 C 语言的 PCRE,就必须通过 CGO 来调用。而 CGO 的上下文切换成本极高,更致命的是,它会彻底破坏 Go 引以为傲的“跨平台交叉编译”能力。你再也不能在一个简单的 go build 后,把二进制文件无痛丢到任何 Alpine 容器里了。

因此,Go 团队做出了第一个艰难的决定:完全使用纯 Go 语言,从零手写一个正则表达式引擎。

脱离了 C 语言几十年的底层优化积累,用原生代码去硬刚别人的 C 引擎,这是 Go 看起来“慢”的表层原因。

但这,仅仅是冰山一角。

路线之争:为了防止系统“猝死”,Go 抛弃了速度

真正让 Go 正则变得“慢”的,是算法架构上的降维选择。这牵扯到 Go 语言的缔造者之一、大神 Russ Cox (rsc) 的一段往事。

在正则表达式的底层世界里,存在着两大流派:

  1. 基于回溯(Backtracking)的 NFA 引擎:代表人物是 PCRE(被 Python、Java、PHP 广泛使用)。
  2. 基于 Thompson NFA / DFA 的引擎:代表人物是 RE2(被 Go、Rust 采用)。

PCRE 引擎极快,它支持各种花里胡哨的语法(如前瞻断言 Lookaround、反向引用 Backreferences)。它的算法逻辑是“不撞南墙不回头”的深度优先搜索(DFS)。在匹配正常字符串时,它快如闪电。

但它有一个极其致命的死穴:ReDoS(正则表达式拒绝服务攻击)。

想象一下你写了一个看似无害的正则:

^([a-zA-Z0-9]+\s?)+$

如果黑客故意传入一个极其恶意的字符串:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!(注意最后的感叹号)。

PCRE 引擎会陷入可怕的“灾难性回溯”。它会尝试所有可能的组合,时间复杂度瞬间飙升到 O(2^n) 级。短短几十个字符的输入,能让单核 CPU 满载运行几年都算不出结果!

2019 年,互联网巨头 Cloudflare 就因为在 WAF 防火墙中写错了一个极其简单的正则表达式,CPU资源瞬间耗尽,导致全球80% 的通过 Cloudflare 代理的网站受到影响,陷入瘫痪长达 27 分钟。这就是 PCRE 回溯引擎的恐怖破坏力。

Russ Cox 在设计 Go 的 regexp 包时,定下了一条铁律:系统安全与可预测性,绝对高于单次请求的极限性能。

因此,Go 彻底抛弃了危险的回溯引擎,选择了基于 Thompson NFA 的算法(源自他之前在Google主导设计的 C++ RE2 引擎)。这种算法保证了匹配时间永远是线性复杂度 O(n)

无论黑客传入多么恶意的字符串,Go 的正则引擎绝对不会发生灾难性回溯。它牺牲了在美好情况下的极致快感,换取了在极端恶劣环境下的金身不坏。

这算是 Go 团队最顶级的“克制”吧。

硬核剖析:Go 的正则,时间到底去哪了?

既然算法是 O(n) 的,为什么 Go 依然比同样采用 RE2/DFA 思想的 Rust 慢那么多呢?

如果你去追踪 Go 官方的 Issue #19629Issue #11646,通过 pprof 分析 Go 正则匹配的 CPU 耗时,你会看到几个令人头疼的瓶颈:

1. 沉重的 UTF-8 解析税

Rust 和 C 的很多正则引擎,底层是直接在“字节(Byte)”级别游走的。而 Go 为了贯彻它对 Unicode 的原生支持,regexp 包在内部极其频繁地将输入流解码为 Rune(Go 的 Unicode 字符单位)。这种逐个解析 Rune 的操作,带来了巨大的计算开销。

2. NFA 虚拟线程的内存震荡

在 Go 的底层源码中,你可以看到耗时最高的两个函数是 (machine).add 和 (machine).step。

Go 是通过维护两个“状态队列(稀疏集)”来模拟 NFA 的并行推进的。每读取一个字符,引擎就要把所有可能的状态添加到下一个队列中。这导致了海量的内存重分配(Allocation)和切片拷贝。哪怕是匹配一个简单的长字符串,底层都在疯狂地挪动内存。

既然这么慢,为什么不把 C++ RE2 里那个极速的 DFA(确定性有限状态自动机)移植到 Go 里呢?

Issue #11646 记录了这次尝试。开发者 Michael Matloob 曾经试图将 RE2 的 DFA 移植过来,但被 Russ Cox 拦下了。原因很直接:DFA 虽然快,但它在运行时会动态生成大量的状态,如果不加以严格限制,极易引发内存耗尽(OOM)。在 Go 带有 GC 的内存模型下,频繁创建和销毁庞大的 DFA 状态缓存,会让垃圾回收器不堪重负。

于是,Go 的标准库在“安全、内存、性能”的三角博弈中,选择了妥协于现状。

社区的探索:SIMD 降维打击与 100倍加速的 coregex

官方的克制固然令人敬佩,但对于身处一线的业务开发者来说,由于正则太慢导致的 CPU 告警,是实实在在的痛点。

“既然官方不愿意改,那我们就自己造轮子!”

在近期的 Issue #26623 中,一位名为 kolkov 的开发者带着他的开源库 coregex 杀入了战场,向 Go 标准库发起了直接的挑战。

coregex 是一个完全用纯 Go 编写的正则库,它的出现直接将 Go 的正则性能拉到了与 Rust 并驾齐驱,甚至在某些场景下超越 Rust 的境地。

它是怎么做到的?它在底层祭出了几个大杀器:

  1. SIMD 预过滤(Prefilters):它使用了手写的汇编代码(AVX2/SSSE3 指令集),将正则中的静态字符串提取出来,利用 CPU 的向量化指令,一次性对比 32 个字节。像匹配 .*.txt 这种正则,速度直接飙升了 1500倍
  2. 带缓存的 Lazy DFA:它绕过了标准库每次都重算 NFA 的毛病,在运行时动态构建 DFA 缓存,大幅消除了内存分配。
  3. 写时复制(COW)的捕获组:标准库在处理提取子串时会疯狂分配切片。coregex 通过切片状态共享,让内存分配直接减少了 50%。

在 kolkov 提供的 CI 跑分中,在 6MB 的输入下,coregex 处理邮箱、URI 的耗时仅为 1.5 毫秒,而标准库耗时高达 260 毫秒。足足快了 170 倍!

然而,这段极其硬核的改进,依然很难入Go团队法眼,更不用谈在短期内被合并进 Go 的标准库。

一方面,Go 官方目前正在推进自己的内建 SIMD 方案(Issue #73787),不想接入手写的汇编代码;另一方面,社区大牛 Ben Hoyt 在使用 coregex 时发现,如果开启 Longest() 模式(最长匹配模式),这个库的性能会发生严重退化。

这再次印证了标准库开发的残酷:在某几个特定场景下跑到全宇宙第一很容易,但要在一套 API 里无死角地兜底全世界所有的奇葩正则输入,难如登天。

在 Go 中写正则的正确姿势

大致了解了底层原理,回到日常开发中,我们该如何应对 Go 正则的性能瓶颈?作为高级 Go 开发者,请务必将以下三条军规刻在脑子里:

第一条:能不用正则,就坚决不用

如果你只是想检查字符串是否包含子串,或者进行简单的前后缀匹配,永远优先使用 strings.Contains()、strings.HasPrefix() 等内置函数。 它们底层有优化的实现,在这样简单场景下,速度是 regexp 包不可比拟的。

第二条:将编译前置,远离循环

如果你翻看新手代码,最常见的低级错误就是在 for 循环或者每次 HTTP 请求里调用 regexp.Compile()。

正则的编译过程(生成 NFA 字节码)极其消耗 CPU。请永远在全局变量或 init() 函数中使用 regexp.MustCompile(),将其编译好并复用。Go 的 Regexp 对象是并发安全的,随便多 Goroutine 调用。

第三条:在极端性能要求下,打破“洁癖”

如果你的核心业务(比如高频日志清洗、海量数据 ETL)确实被 regexp 卡住了脖子,不要硬抗。

你可以选择引入通过 CGO 调用 PCRE的Go binding库(比如https://github.com/GRbit/go-pcre),但要注意防范 ReDoS 攻击,或google/re2的Go binding(比如https://github.com/wasilibs/go-re2),又或是在业务侧尝试社区的野路子 coregex。在生存面前,架构的“洁癖”是可以适当妥协的。

小结

“为什么 Go 的正则这么慢?”

这并非一个简单的工程失误。它是一道分水岭,隔开了“追求跑分好看的玩具代码”与“守护千万级并发集群的生产级设计”。

Russ Cox 宁愿忍受整个开源界的群嘲,也没有为了刷榜而去引入危险的回溯引擎。这或许就是 Go 语言能够成为云原生时代头部语言的原因:不盲目追求上限的巅峰,而是死死守住安全下限。

参考资料

  • https://www.reddit.com/r/golang/comments/1rr2evh/why_is_gos_regex_so_slow/
  • https://github.com/golang/go/issues/26623
  • https://github.com/golang/go/issues/19629
  • https://github.com/golang/go/issues/11646
  • https://swtch.com/~rsc/regexp/

今日互动探讨:

在你的日常开发中,有没有被由于“写了糟糕的正则表达式”而导致 CPU 飙升 100% 的惨痛经历?你又是如何排查和优化的?

欢迎在评论区分享你的血泪史


认知跃迁:读懂底层机制,才能看透系统架构的本质

从放弃 CGO 选择纯 Go 实现,到防范 ReDoS 采用 NFA,再到社区为了榨干 CPU 性能而引入 SIMD。Go 语言的每一个看似“不合理”的设计背后,都隐藏着深邃的系统级考量。

然而,令人遗憾的是,很多开发者写了五六年的 Go 代码,遇到性能瓶颈依然只能靠“瞎猜”和“重启”。他们对 Go 的内存逃逸、Goroutine 调度机制以及标准库的底层数据结构一无所知。

如果你渴望突破“熟练调包侠”的瓶颈,想要像 Russ Cox 这样的顶级大厂架构师一样,看透 Go 语言背后的底层逻辑,建立起自己坚不可摧的技术护城河——

我的极客时间专栏 Tony Bai·Go语言进阶课 正是为你量身定制。

在这 30+ 讲极其硬核的内容中,我不仅带你剥开语法糖,深挖 Goroutine 调度、Channel 哲学;更会带你全面吃透 Go 的工程化实践,把底层性能调优背后的逻辑一次性讲透。

目标只有一个:助你完成从“Go 熟练工”到“能做顶级架构决策的 Go 专家”的蜕变!

扫描下方二维码,加入专栏。不要用战术上的勤奋,掩盖战略上的懒惰。让我们一起用架构师的视角,重新认识 Go 语言。


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

🔲 ☆

Go 1.26 中值得关注的几个变化:从 new(expr) 真香落地、极致性能到智能工具链

本文永久链接 – https://tonybai.com/2026/02/14/some-changes-in-go-1-26

大家好,我是Tony Bai。

北京时间 2026 年 2 月 10 日,Go 团队正式发布了 Go 1.26

时光飞逝,距离我在博客中写下《Go 1.26 新特性前瞻》已经过去了两三个月。在那篇文章中,我们基于Go 1.26开发分支对这一版本进行了初步的探索。如今,随着正式版的落地,那些曾经躺在 proposal 里的构想、存在于草案中的特性,终于尘埃落定,成为了我们手中实实在在的工具。

官方 Go 1.26 Release Notes 中平实的语言背后,隐藏着巨大的工程价值。如果用一个词来形容 Go 1.26,我认为是“精益求精的工程化胜利”

与引入泛型的 Go 1.18 或引入函数迭代器Go 1.23 不同,Go 1.26 并没有带来颠覆性的语言范式改变,但它在编码体验、底层性能以及工具链智能化这三个维度上,都交出了一份令人惊艳的答卷。从千呼万唤始出来的 new(expr) 语法糖,到默认启用的 Green Tea GC,再到重构后的 go fix,每一个改动都切中了工程实践中的痛点。

本文将基于官方发布的 Release Notes,结合我之前的深度分析,为你全景式解析 Go 1.26 中那些最值得关注的变化。

语言变化:不仅是语法糖,更是生产力

new(expr):指针初始化的终极解法

在 Go 语言的日常开发中,我们经常面临一个尴尬的场景:如何获取一个字面量(Literal)或表达式结果的指针?

在 Go 1.26 之前,我们无法直接对字面量取地址(&10 是非法的)。为了初始化一个包含指针字段的结构体(这在 JSON/Protobuf 的可选字段、数据库 ORM 映射中极其常见),我们不得不引入临时变量,或者定义辅助函数:

// Go 1.26 之前:繁琐的临时变量或辅助函数
func IntP(i int) *int { return &i }

timeoutVal := 30
conf := Config{
    Timeout: &timeoutVal,   // 必须先定义变量
    Retries: IntP(3),       // 或者依赖辅助函数
}

这种写法不仅啰嗦,还打断了代码的阅读流。社区为此发明了无数个 ptr 库,甚至很多项目里都有一个 util.go 专门放这些 helper。

Go 1.26 终于原生解决了这个问题。 内置函数 new() 的语法得到了扩展,现在它允许接收一个表达式作为参数,并返回指向该表达式值的指针。

// Go 1.26:优雅的内联初始化
// 完整代码:https://go.dev/play/p/kEYZC3W6-sa
conf := Config{
    Timeout: new(30),          // 直接获取整型字面量的指针
    Role:    new("admin"),     // 直接获取字符串字面量的指针
    Active:  new(true),        // 布尔值也不在话下
    Start:   new(time.Now()),  // 甚至是函数调用的结果
}

这不仅是一个语法糖,它极大地提升了配置对象、API 请求体构建时的代码可读性,消除了大量无意义的中间变量,让代码变成了声明式的“一行流”。

关于这个特性的演变历程以及社区的讨论细节,可以参考我之前的文章《从 Rob Pike 的提案到社区共识:Go 或将通过 new(v) 彻底解决指针初始化难题》。

泛型约束的自我引用

Go 1.26 解除了泛型类型在类型参数列表中引用自身的限制。这意味着我们现在可以定义更加复杂的递归数据结构或接口约束。

// 以前这是非法的,现在合法了
type Adder[A Adder[A]] interface {
    Add(A) A
}

func algo[A Adder[A]](x, y A) A {
    return x.Add(y)
}

这一改变虽然对日常业务代码影响较小,但对于编写通用库、ORM 框架或复杂算法库的开发者来说,它消除了一个长期存在的类型系统痛点,让泛型的表达能力更上一层楼,简化了复杂数据结构的实现。

关于这个特性的演变历程以及社区的讨论细节,可以参考我之前的文章《Go 泛型再进化:移除类型参数的循环引用限制》。

运行时与编译器:看不见的性能飞跃

Go 1.26 在“看不见的地方”下了苦功,不仅让 GC 焕然一新,还解决了 Cgo 和切片分配的性能瓶颈。

“Green Tea” GC:默认启用的性能引擎

Go 1.25 作为实验特性登场后,代号为 “Green Tea” 的新一代垃圾回收器在 Go 1.26 正式转正,成为默认 GC。

Green Tea GC 是 Go 运行时团队针对现代硬件特性和分配模式进行的一次深度重构。它主要优化了小对象的标记和扫描过程,通过更好的内存局部性(Locality)和 CPU 扩展性,显著提升了 GC 效率。

  • 开销降低:根据官方发布说明,在重度依赖 GC 的真实应用中,GC CPU 开销降低了 10% – 40%。这意味着你的微服务可能在不增加硬件资源的情况下,吞吐量获得直接提升。
  • 向量化加速:在支持 AVX 等向量指令集的现代 CPU(如 Intel Ice Lake 或 AMD Zen 4 及更新架构)上,Green Tea GC 会利用 SIMD 指令加速扫描,带来额外的性能提升。

这对于微服务、高并发 Web 应用等存在大量临时小对象分配的场景来说,是一次免费的性能升级。你无需修改一行代码,只需升级 Go 版本。

关于 Green Tea GC 的深层原理和架构演进,我在《Go 官方详解“Green Tea”垃圾回收器:从对象到页,一场应对现代硬件挑战的架构演进》一文中有详细解读。

Cgo 调用提速 30%

对于依赖 SQLite、图形库、系统底层 API 或其他 C 库的 Go 应用,这是一个巨大的利好。Go 1.26 将 Cgo 调用的基准运行时开销(Baseline Runtime Overhead)降低了约 30%。这意味着跨语言调用的“税”被进一步降低,Go 在系统编程和嵌入式领域的竞争力再次提升。

编译器进化:栈上分配切片底层数组

对于 Go 开发者而言,“栈分配(Stack Allocation)”由于无需 GC 介入,其效率远高于堆分配。

Go 1.26 的编译器进一步增强了逃逸分析能力。编译器现在能够在更多场景下,将切片的底层数组(Backing Store)直接分配在栈上。这主要针对那些使用 make 创建但大小非固定(但在一定范围内)的切片场景。

这一改进直接减少了堆内存的分配次数,进而降低了 GC 扫描的压力。如果你对这一编译器优化技术感兴趣,或者想了解如何利用 PGO 驱动逃逸分析,推荐阅读《PGO 驱动的“动态逃逸分析”:w.Write(b) 中的切片逃逸终于有救了?》。

实验性特性:Goroutine 泄露分析

Goroutine 泄露一直是 Go 并发编程中隐蔽且棘手的难题。Go 1.26 引入了一个名为 goroutineleak 的实验性 Profile(需通过 GOEXPERIMENT=goroutineleakprofile 开启)。

与传统的泄露检测工具不同,该功能基于 GC 的可达性分析。它能检查那些处于阻塞状态的 Goroutine,看它们等待的并发原语(如 Channel、Mutex)是否已经“不可达”。如果一个 Goroutine 等待的 Channel 没有任何活跃的 Goroutine 能够引用到,那么这个 Goroutine 就被判定为“永久泄露”。

这种检测机制在理论上保证了极低的误报率。这源自 Uber 的内部实践,我在《Goroutine泄漏防不胜防?Go GC或将可以检测“部分死锁”,已在Uber生产环境验证》一文中对此进行了详细介绍。

工具链:更智能、更规范

go fix 的重生:Modernizers 与内联

Go 1.26 对 go fix 命令进行了彻底重写。它不再是一个简单的语法修补工具,而是基于 Go Analysis Framework 构建的强大现代化引擎。

新版 go fix 引入了 “Modernizers” 的概念。它包含了几十个分析器,不仅能修复错误,还能主动建议并将你的代码升级为使用最新的语言特性或标准库 API。

除了 “Modernizers”,新版 go fix 另一个重磅功能是基于 //go:fix inline 指令的自动内联与迁移机制。

  • 函数内联:如果一个函数被标记了 //go:fix inline,go fix 分析器会建议(并自动执行)将所有对该函数的调用替换为函数体的内容。这对于废弃旧 API 极为有用。例如:

    // Deprecated: prefer Pow(x, 2).
    //go:fix inline
    func Square(x int) int { return Pow(x, 2) }
    

    当用户调用 Square(10) 时,go fix 会将其自动重写为 Pow(10, 2),从而实现平滑迁移。

  • 常量内联:同样的机制也适用于常量。如果一个常量定义引用了另一个常量并标记了 //go:fix inline,所有对旧常量的引用都会被自动替换为新常量。

    //go:fix inline
    const Ptr = Pointer // Ptr 的使用者会被自动迁移到 Pointer
    
  • 跨包/跨版本迁移:这一机制甚至支持跨包迁移。例如,当库升级到 v2 版本时,可以在 v1 包中定义一个内联函数,将调用转发给 v2 包。go fix 会自动将用户代码中的 v1 调用替换为 v2 调用,从而实现低风险的大规模自动化重构。

这种基于源码注释的指令机制,为库作者提供了一种标准化的手段来引导用户升级,彻底改变了过去手动修改或编写复杂迁移脚本的痛苦历史。

go mod init 的版本策略变更:兼容为先

这是一个容易被忽视但影响深远的改动。

在以前,当你用 Go 1.25 工具链运行 go mod init mymod 时,生成的 go.mod 会默认写入 go 1.25。这意味着你的模块无法被 Go 1.24 的用户引用。

从 Go 1.26 开始,go mod init 变得更加“克制”:

  • 稳定版工具链:默认生成 1.(N-1).0 版本。例如,使用 Go 1.26 初始化,go.mod 将写入 go 1.25.0
  • 预览版工具链:默认生成 1.(N-2).0 版本。

这一策略鼓励开发者创建兼容性更好的模块,避免无意中切断了对次新版 Go 用户的支持。这是一个对生态系统非常友好的改动。在后续的文章中,我们会专题对此特性进行说明。

Pprof 默认火焰图

go tool pprof -http 现在默认展示火焰图(Flame Graph)视图,而不是原来的有向图。这顺应了性能分析领域的趋势,火焰图在展示调用栈耗时占比时更为直观,利于快速定位热点。

标准库:补齐短板,拥抱未来

testing 包:测试产物归档 ArtifactDir

在 CI/CD 环境中,集成测试失败时,我们往往希望能看到当时的日志文件、截图或数据库 Dump。过去,我们需要自己拼接临时目录路径,并祈祷它没有被清理。

Go 1.26 为 testing.T 和 B 新增了 ArtifactDir() 方法:

  • 该方法返回一个专门用于存放测试产物的目录路径。
  • 配合 go test -artifacts=./out 参数,可以自动将这些产物收集到指定位置。

这结束了每个项目自己造轮子管理测试临时文件的混乱局面。关于这一特性的详细讨论,可以参考《Go testing包将迎来新增强:标准化属性与持久化构件API即将落地》。

log/slog:原生多路输出 MultiHandler

自 slog 引入以来,如何将日志同时输出到控制台和文件一直是个高频问题。Go 1.26 新增了 slog.NewMultiHandler,正式在标准库层面支持了日志的“扇出(Fan-out)”。

它会将日志分发给多个 Handler,只要任意一个子 Handler 处于 Enabled 状态,日志就会被处理。这意味着我们不再需要引入第三方库来实现这一基础功能。更多背景参考《slog 如何同时输出到控制台和文件?MultiHandler 提案或将终结重复造轮子》。

errors:泛型版 AsType

errors.As 一直是 Go 错误处理中容易“踩坑”的 API(需要传递指针的指针,否则会 Panic)。Go 1.26 引入了泛型版本的 errors.AsType

// Old: 容易写错,运行时反射
var pathErr *fs.PathError
if errors.As(err, &pathErr) { ... }

// New (Go 1.26): 类型安全,编译期检查
if pathErr, ok := errors.AsType[*fs.PathError](err); ok { ... }

这不仅更安全,而且由于省去了复杂的运行时反射开销,性能也更好。详见《泛型重塑Go错误检查:errors.As的下一站AsA?》。

拥抱迭代器与零拷贝

  • reflect 包迭代器:新增 Type.Fields(), Type.Methods() 等方法,返回迭代器序列,允许使用 for range 循环遍历结构体字段,替代了笨拙的索引遍历。
  • bytes.Buffer.Peek:新增 Peek 方法,允许在不推进读取位置的情况下查看缓冲区数据,为高性能解析场景提供了便利。详见《Go 零拷贝“最后一公里”:Peek API背后的设计哲学与权衡》。

安全增强

小结

Go 1.26 是一个务实、丰满且充满诚意的版本。

它没有追求华而不实的新奇法,而是通过 new(expr) 和 go fix 提升开发者的幸福感;通过 Green Tea GC 和编译器优化提升运行时的性能;通过 go mod init 的策略调整和标准库的补全,提升生态系统的健壮性。

建议大家在详细阅读官方 Release Notes 后,尽快制定升级计划,享受 Go 1.26 带来的红利。


你的升级计划是?

Go 1.26 带来了诸多实惠的工程优化。在你看完这些变化后,最想立刻在项目里用起来的特性是哪个?你所在的团队是否已经开始规划升级到这个版本了?

欢迎在评论区聊聊你的看法!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

❌