网站建设公司比较,扑克直播软件app开发,网站建设服务亮点,网站改版工作方案DevCycle 团队与 Jon 和 Kris 就 WebAssembly (Wasm) 和 Go 进行了深入讨论#xff01;在对 Wasm 的所有内容进行了高层次的讨论之后#xff0c;我们了解了他们如何以酷炫有趣的方式在生产中使用它。我们以一个热门的非流行部分结束#xff0c;其中包括“ChatGPT”、“LLM”…DevCycle 团队与 Jon 和 Kris 就 WebAssembly (Wasm) 和 Go 进行了深入讨论在对 Wasm 的所有内容进行了高层次的讨论之后我们了解了他们如何以酷炫有趣的方式在生产中使用它。我们以一个热门的非流行部分结束其中包括“ChatGPT”、“LLM”、“NFT”和“AGI”等流行词 本篇内容是根据2024年7月份#275 Go Wasm音频录制内容的整理与翻译
过程中为符合中文惯用表达有适当删改, 版权归原作者所有. Jon Calhoun: 大家好欢迎来到 Go Time。我今天邀请到了三位嘉宾。首先Kris我们的第一个嘉宾是 Jonathan Norris他是 DevCycle 的联合创始人兼 CTO。他开发了多个面向开发者的产品并且在设计和构建大规模可扩展系统方面有丰富的经验。Jonathan你好吗
Jonathan Norris: 嗨我很好。很高兴来到这里也非常期待聊聊我们正在做的工作还有一些关于 WebAssembly 和 Go 的话题。
Jon Calhoun: 很高兴你能来。我们的下一位嘉宾是 Adam Wootton他是 DevCycle 的首席架构师负责基础设施、性能和系统可扩展性。Adam你好吗
Adam Wootton: 我很好今天很期待这次对话。
Jon Calhoun: 很高兴你能来。第三位嘉宾是 Brad Van Vugt他之前曾来过我们的节目讨论过 Battlesnake这是他创办的一家公司。Battlesnake 今年早些时候被 DevCycle 收购了现在 Brad 是 DevCycle 的战略与增长主管。Brad你好吗
Brad Van Vugt: 很好很好。你怎么样Jon
Jon Calhoun: 我也挺好的。感觉你已经有一阵子没上我们的节目了。
Brad Van Vugt: 是的确实有一段时间了。
Jon Calhoun: 其实时间并没有很久但感觉就是这样。
Brad Van Vugt: 很高兴能够回来。
Jon Calhoun: 还有 Kris 也和我们在一起。Kris你好吗
Kris Brandow: 我很好。很高兴能回到节目中。我之前有段时间没出现了所以……
Jon Calhoun: 是的我觉得我们很久没一起主持节目了。
Kris Brandow: 是啊大概有一年左右了吧。
Jon Calhoun: 不知道怎么回事总觉得我会随机出现在一些节目中总是和同样的两个人一起我也不知道是怎么发生的……好吧今天我们要讨论 WebAssembly。首先我想从介绍 WebAssembly 开始为什么大家应该关心它然后我们可以聊聊 Jonathan、Adam 和 Brad 在 DevCycle 使用它的经验以及你们如何使用它构建不同的东西从中获得了哪些价值。那么首先什么是 WebAssembly为什么大家应该关心它
Jonathan Norris: 好的我可以先说一下。WebAssembly 基本上是一个内存安全的沙盒执行环境最初是为了将底层的原生代码引入网页而构建的……所以显然它的品牌名称是 WebAssembly但实际上WebAssembly 已经演变成一种跨平台的方式可以在多个不同的环境中以接近原生的速度执行代码。这些环境包括从网页到边缘计算的无服务器环境甚至在你的服务器中以及支持多种不同的语言类型……它们的设计目标是创建可以快速启动的小型二进制文件并能够在非常接近原生速度的情况下执行同时还具有非常紧密的安全性和沙盒环境……这大致是 WebAssembly 的定义。
Jon Calhoun: 很棒。那么你们想从哪里开始聊这个话题你们想从人们可能开始使用 WebAssembly 的地方开始还是聊聊在 WebAssembly 出现之前人们通常是怎么做的
Jonathan Norris: 我们可以谈谈这两方面。我们可以先从 WebAssembly 的常见使用场景开始。我认为 WebAssembly 的一些最常见的应用场景是为网页浏览器带来一些可能原生不存在的功能。你可以想想 Figma……对于那些不知道的人Figma 是一个设计工具允许你在基于浏览器的环境中完成整个设计工作流程而这主要是通过一系列 WebAssembly 库在幕后支持的。如果你想进行深度数据分析或者运行一些像 Python 或 R 这种工具链中的操作也有很多这类功能可以通过 WebAssembly 在浏览器中实现。
还有一些游戏……很多人可能在 Hacker News 上看到过你可以在浏览器中运行《毁灭战士》这样的老游戏。这些游戏基本上就是人们将 C 或 C 的代码库编译成 WebAssembly 并加载到浏览器运行时中让你可以在浏览器中运行这些游戏。但实际上我认为 WebAssembly 背后的推动力是创造那种可移植的跨平台二进制文件这些文件可以在浏览器中执行但现在很多情况下也可以在服务器端甚至边缘计算中运行。边缘计算在 WebAssembly 上真的开始兴起因为你可以在纳秒级启动一个 WebAssembly 运行时或者在大多数情况下以毫秒级启动取决于你的二进制文件有多大并且可以非常快速地扩展你的边缘计算。所以在边缘使用 WebAssembly 的势头非常强劲。我们也在边缘使用 WebAssembly同时我们也在多个不同的服务器端语言中使用它来构建 SDK。
Jon Calhoun: 我想能够在边缘运行并执行这些操作是你提到的原因之一……像 Figma 这样的工具理论上它们可以用 JavaScript 构建。我不知道性能会如何但理论上你应该可以用 JavaScript 构建几乎任何软件。那么这是不是意味着问题不仅仅是 JavaScript 能否完成而是你可以将它部署在边缘并做所有额外的事情抱歉我感觉我在解释时有点混乱……
我想问的是是什么主要动机促使人们从尝试用 JavaScript 重写所有库转向 WebAssembly我觉得你提到的是边缘计算等问题是否准确
Adam Wootton: 我认为这还涉及到性能方面的问题。正如你提到的Figma 可以用 JavaScript 编写但实际上不可能因为你永远无法用纯 JavaScript 编写像 Figma 这样复杂的东西尤其是涉及到很多底层计算的情况。JavaScript 的速度根本不够快。WebAssembly 为你提供了一个更接近硬件的环境来执行代码所以编写高性能应用程序变得更加容易。而对于像 Figma 这样的应用你需要处理大量的数据搬移、处理和转换……这些操作都无法在 JavaScript 中高效地编写。你需要某种编译层来处理这些事情。所以我认为这是 WebAssembly 的另一个巨大优势。
Brad Van Vugt: JavaScript 的神奇之处在于它实际上可以非常快因为 V8 引擎是一个非常神奇的软件。如果你研究过 V8 的内部运行机制以及它如何优化 JavaScript 代码你会发现它真的是一个神奇的作品数以百计甚至数百万的开发者投入了无数的时间才使它成为这么一个惊人的东西。因此V8 可以将你的 JavaScript 运行得非常快接近原生速度。但由于它是一个即时编译器JIT compiler它需要时间来达到这个速度。所以第一次执行 JavaScript 代码时会比较慢而随着 JIT 编译器和 V8 以及 SpiderMonkey 等其他引擎开始工作并将你的 JavaScript 代码编译为越来越底层的代码你的代码会越来越快。但使用 WebAssembly你可以直接编译到接近原生速度运行用 Go、C#、Rust 或 C 编写的相同代码并立即获得类似的性能而无需等待即时编译器的优化。
Jon Calhoun: 好的。既然这是 Go Time显然很多听众想知道如何将 Go 与 WebAssembly 结合使用。那么如果有人想开始使用 WebAssembly 和 Go该怎么做
Brad Van Vugt: 有两种方法。你可以将现有的 Go 代码编译成 WebAssembly……有一些相关的项目可以实现这一点。你可以将 Go 代码打包成一个 WebAssembly 二进制文件如果你想在边缘执行这个 Go 库或者在网页环境甚至移动环境中执行它---因为 WebAssembly 可以在移动设备上运行---你可以很简单地将 Go 代码编译成 WebAssembly 二进制文件。这个过程非常简单编译目标可以通过搜索引擎找到。
这里给大家的建议是标准编译会生成比较大的二进制文件比如多兆字节的文件虽然听起来不大但在 WebAssembly 世界中你想要的是小到个位数 KB 的二进制文件这样它们可以被快速下载并加载到运行时中。因此我的建议是使用 TinyGo它可以大大减少输出的二进制文件大小。当然它对可以使用的 Go 功能有一些限制但如果你想这样做TinyGo 是一个不错的选择。
如果你想在 Go 中执行用其他语言编写的 WebAssembly 代码Wasmtime 运行时是我们强烈推荐的。它们是 Bytecode AllianceWebAssembly 背后的开源联盟主要支持的运行时现在已经经过大量测试并得到良好支持。这些就是我们在所有不同语言的 SDK 中自己使用的运行时。
Jon Calhoun: 那在实际编写代码时感觉会是怎样的我在想一个例子。有一些库允许你用 Go 编写代码基本上生成 React或者类似的东西。但很多情况下你最终不得不编写一些非常特定的代码感觉不像在写 Go 代码而是 Go 和 React 的混合体。那么在使用 WebAssembly 时你需要大幅调整对 Go 代码的思考方式吗还是感觉在写真正的 Go 代码
Brad Van Vugt: 是的我觉得这是 WebAssembly 的挑战之一。你需要明确定义你的接口我认为这是目前使用 WebAssembly 最大的挑战之一。你必须真正理解本机代码和 WebAssembly 代码之间的接口才能构建出优秀的功能。Adam 可能可以进一步解释这一点但这是我们遇到的最大挑战。如果你想让 WebAssembly 代码运行得高效---它在处理 CPU 周期方面表现出色但在管理内存和数据传输方面不太好。所以你需要非常仔细地考虑传递到 WebAssembly 运行时中的数据量以及从中获取的数据量并对这些路径进行优化。
Adam Wootton: 是的让我补充一下。我们遇到的一个问题是无法在内存中直接交换复杂的数据结构无法在 Go 和 WebAssembly 之间共享。因此你必须考虑如何以一种可以高效序列化和反序列化的方式传递数据。你不能简单地将一个类的实例传递给 WebAssembly 并直接使用它。但你可以考虑如何将这个类转化为一种在内存中可以被 WebAssembly 读取的表示形式。
因此并没有一种一对一的映射方式比如“这个对象在 WebAssembly 中变成那个对象”你需要将其转化为某种内存表示形式。我们最终使用了 protobuf 作为序列化工具但也有其他方法。我记得 Google 有一个类似 Frame Buffer 的库……我们最初使用的是 JSON但显然它比 protobuf 慢得多。所以有很多策略可以用来在执行 WebAssembly 模块时高效地传递数据。
Brad Van Vugt: 如果你只是在处理二进制数据那 WebAssembly 就非常高效了。有很多使用 WebAssembly 进行视频编码或音频过滤的例子……我不会感到惊讶如果我们今天用的工具 Riverside 也在幕后使用了 WebAssembly 模块来处理音频过滤、视频编码等工作。所以在这些用例中WebAssembly 可以非常高效地处理结构化的二进制数据并在 JavaScript 端或 Go 端和 WebAssembly 端之间传递数据缓冲区。
所以有很多图像处理的 WebAssembly 二进制文件可以让你在浏览器中进行图像分析或过滤并且比在 JavaScript 中做得更快这些都是通过处理二进制数据来实现的。
Jon Calhoun: 当 Brad 联系我讨论 WebAssembly 时他提到你们在 DevCycle 有一些非常有趣的 WebAssembly 使用案例。你们能分享一下你们在构建什么项目使用 WebAssembly 的原因或好处吗
Brad Van Vugt 很高兴分享。在 DevCycle我们正在构建一个功能管理工具也就是一个功能标识feature flag工具它需要在多个 SDK 和不同的环境中工作。可以想象对于一个功能标识工具来说我们希望能够支持尽可能多的客户来使用我们的软件。而要用一个小团队做到这一点可能需要你为所有不同的语言创建大量的自定义 SDK或者你可以想办法在多个环境中使用相同的代码库。这就是我们为什么选择 WebAssembly 的原因。我们在之前的产品中已经玩转了这个技术好几年了后来在 DevCycle 我们决定全力投入采用一个通用的 WebAssembly 代码库其中包含了我们所有的核心业务逻辑比如如何决定哪些用户应该被分配到哪个功能标识以及如何决定功能的发布和其他重要的业务决策。我们需要这段代码特别强大经得起各种测试并且尽可能可靠。
通过使用 WebAssembly我们能够创建一个非常稳固的库然后可以在任何需要的地方共享。我们在运行可扩展 API 的工作者workers中使用了这个 WebAssembly 库这些 API 运行在 Cloudflare 的边缘工作者环境中我们还在所有的服务端 SDK 中使用了这个同样的 WebAssembly 代码从 Go、Java、Node.js 到 C\#我想 Python 和其他几个语言版本也很快就会推出。因此作为一个功能标识平台我们可以很自信地支持所有主要的服务端语言并且可以快速构建这些 SDK同时确保它们都能按预期工作因为我们在所有这些 SDK 和 API 中基本上使用了相同的核心代码。这为我们带来了巨大的商业价值并大大减少了我们需要编写的代码量。
Jonathan Norris 我很好奇当时决定采用 WasmWebAssembly的时候---那是在我加入 DevCycle 之前---当时 Wasm 的社区是什么样的Wasm 本身成熟度如何那时我们还没有看到像 Figma 这样的公司在如此大规模上使用 Wasm并从中获得巨大好处… 但 WebAssembly 仍然相对较新还在摸索自己的定位还在寻找它在整个生态系统中的位置… 那么当时 DevCycle 是基于什么背景决定如此坚决地采用 Wasm 的呢
Brad Van Vugt Adam你想接着讲吗
Adam Wootton 当然。我觉得有趣的是我们一直觉得自己在使用这些技术时有点走在前沿。我会说当我们第一次开始使用它时虽然已经有一个相对较大的社区但我们所使用的很多具体工具还比较新。所以这段时间很有意思因为我们看着这个技术随着我们的使用而成长。我们使用的一个主要工具是 AssemblyScript。这个语言基本上看起来像 TypeScript或者说像 JavaScript 的类型版本 TypeScript但它编译成的是 WebAssembly 模块。当我们开始使用它时这个语言还很新可能只发布了不到一年。随着我们的使用我们看到了它的巨大改进也看到了社区的快速增长。我们在他们的 Discord 社区中非常活跃那里有很多人会帮助你解答问题… 所以看到这个生态系统的兴奋和动能不断增长真的很有趣。
( 译者注: AssemblyScript 是一个把TypeScript 转换到WebAssembly 的编译器. 更多可参考 AssemblyScript 入门指南 )
Brad Van Vugt 我会说使用 WebAssembly 在浏览器中的生态系统已经相当成熟。我认为浏览器对 WebAssembly 的支持已经存在很长时间了。我不记得具体的年份但大概是很多年了。实际上我上周在阿姆斯特丹的 KubeCon 上与 WebAssembly 的一些核心人员交谈据我了解WebAssembly 是在大约 12 年前或者说 10 年前开始的。它的历史比大多数人想象的要长得多但最初的目标是将更多底层的代码如 C、Go 和 Rust 代码引入能够在浏览器环境中执行。但真正让社区开始扩展的是将这种安全的小型运行时引入到其他地方比如服务端使用场景、边缘运行时等。这就是社区开始成长的地方。
上周我和一些新兴创业公司聊过他们都在尝试用 WebAssembly 运行时在很多方面取代 Docker 容器尤其是在 Kubernetes 和边缘计算环境中。所以这是一个非常令人兴奋的领域社区也在迅速增长和加速发展。
Kris Brandow 我发现很有趣的是---你提到最初的目标是将一些东西引入浏览器环境。我记得 Unreal Engine (译者注: 即著名的虚幻引擎) 是通过 Emscripten 编译的运行在浏览器里… 那时我们还没有 WebAssembly但大家依旧觉得这太棒了。当时的目标是“让它跑在浏览器里”。我想当时没有人真正想到浏览器其实是一个非常封闭的环境。大多数后端工程师没有特别关注前端所以他们只是认为“哦这就是浏览器它会正常工作的。”但实际上浏览器在沙盒运行方面非常强大。WebAssembly 也必须做到这一点。
( 译者注: 更多可参考 asm.js 和 Emscripten 入门教程 )
所以我一直觉得 WebAssembly 的一个不可思议之处在于我们一直在尝试在服务端进行沙盒化处理但那往往变得很混乱尤其是在虚拟机之外的环境中。所以我觉得这段故事非常引人入胜。
你提到使用 AssemblyScript。我很好奇用 AssemblyScript 写 WebAssembly 的体验是怎样的因为我听说写起来会有点困难。它有点像 TypeScript但有很多地方又不像。而且我知道 WebAssembly 基本上什么都没有。你只得到一个盒子可以在里面运行一些代码但别指望它像真正的计算机那样。
Adam Wootton 是的我会说根据我们的经验使用它确实有很多陷阱。我觉得当你刚开始学习它时它看起来和 TypeScript 非常相似这可能有点迷惑性。因为实际上它在底层根本不像 TypeScript。所以当你对性能敏感时或者对某些细节敏感时你真的需要深入了解它的实际输出弄清楚你的代码究竟在 Wasm 环境中做了什么… 因为你很容易写出非常低效的代码而在 JavaScript 环境中这些低效的代码可能看起来还不错。我想 Jonathan 之前提到过V8 的 JIT 编译器非常擅长在第一次执行某个低效的代码路径后迅速优化它以便下次执行时可以快得多。而在 AssemblyScript 世界中这种情况是不存在的。如果你写的代码在 TypeScript 中看起来不算慢那么在 AssemblyScript 中它可能会很慢。我们还发现随着我们深入使用它越来越多地需要理解底层的内存结构比如它如何为各种标准对象分配内存… 我们必须弄清楚字符串是如何工作的类实例化是如何处理的垃圾回收器什么时候启动… 这涉及很多因素尤其是在我们试图优化性能时。尽管我们很快能写出能够通过所有单元测试的代码并让它正常工作但当我们开始对其进行性能分析和基准测试时我们才意识到“哦我们对如何编写代码的许多假设实际上并不成立我们需要重新考虑一些问题以提高性能。”
Jonathan Norris 是的。为了给大家提供一些背景我们当时有一个 TypeScript 代码库我们基本上希望它能在 WebAssembly 中工作。所以选择 AssemblyScript 对我们来说是一个自然的选择。我们基本上拿了那个 TypeScript 代码库然后基本上逐步将所有高级类型更改为低级原始类型。然后我们还必须移除一些不能在 AssemblyScript 中使用的东西比如闭包。所以我们不得不将代码重构回低级原始类型感觉好像回到了更简单的时代。我们能够在不到一周的时间内将我们相当庞大的代码库转换为 AssemblyScript并且让它通过了我们所有的测试并且功能正常… 所以我认为这给我们留下了非常深刻的印象因为我们能够如此快速地让它运行起来… 但正如我们最近在优化 Go SDK 时遇到的问题一样尤其是在纳秒级别的优化方面AssemblyScript 的确给我们带来了一些障碍。
Brad Van Vugt 是的我希望我们能进一步深入探讨这个问题。我觉得 DevCycle 的使用场景在这个领域有点独特。而 Jonathan你已经提到过一些了我们谈论的是超低的纳秒级延迟谈论的是边缘计算谈论的是尽可能接近用户的浏览器环境… 所以我认为 DevCycle 的使用场景远远超出了 WebAssembly 的跨编译和共享二进制文件的好处实际上我们在谈论的是超微优化和大规模性能问题特别是从 DevCycle 的基础设施运作来看。所以我希望我们能深入探讨一些技术细节比如你们是如何从能够运行的 WebAssembly 代码优化到让它真正跑得非常快的特别是在 Go 运行时环境下
Jonathan Norris 是的我先介绍一下这个优化问题的背景Adam 可以深入谈谈一些细节… 我们受到了一个新客户的挑战他们运行着一个全球 CDN 网络而这个 CDN 是基于 Go 代码库构建的。我们当时的想法是“好吧这是一个真正的挑战。我们必须接受这个挑战尽可能优化我们的 WebAssembly 代码以尽量减少对他们 CDN 代码的性能影响因为他们可能一次要评估几十到几百个功能标识。” 所以这是我们面临的挑战我们有点天真地接受了这个挑战决定深入研究 WebAssembly 代码中的每一个小细节看看我们能做些什么来优化它的性能。是的沿途我们确实发现了一些有趣的事情。我不知道 Adam 你是否想从我们开始的地方讲起… 因为我们一开始的起点并不好但最终我们取得了不错的成绩。
Adam Wootton: 是的。正如我之前提到的我们的初衷只是希望让这个项目的功能与原来的 TypeScript 代码保持一致。因此我们并没有特别在意性能问题。直到我们开始深入研究性能指标时才意识到我们需要做多少工作才能达到目标。我们最初的性能指标---基本上是通过某个变量对用户进行评估来衡量的。DevCycle SDK 的工作原理是你询问它“给定这个用户数据这个变量的值是什么” 这就是功能标志平台的概念根据这个用户他们应该获得这个变量的什么值在我们最初的代码版本中每次评估的时间大约是几毫秒这实在是太慢了。我们讨论的是一个CDN它的目标是让整个请求处理器的时间在10到15毫秒之间而这个处理器可能需要评估10到100个 DevCycle 变量而我们每个变量的评估时间在原始代码中都需要2到3毫秒。显然这个性能水平是无法接受的。因此我们最初的大部分工作基本上是减少通过模块边界传递的数据量。前面我们提到由于无法直接在主机和 Wasm 代码之间共享复杂的对象因此我们必须传递一组结构化的用户数据和一组从服务器接收的配置数据然后让 Wasm 返回答案“这个变量的值应该是多少”
所以我们最初的主要工作是“我们如何减少传递到边界的数据量尽量精简”最后我们发现我们传递了很多不必要的数据。因此一旦我们减少了这些数据性能就大幅提升从最初的几毫秒缩减到了70微秒虽然大幅改善但70微秒仍然太慢了。为了建立一个基准我们对竞争对手的 SDK 进行了基准测试发现他们的执行时间在每个操作1000到10000纳秒之间而我们的时间则是70000纳秒即70微秒。
所以我们后来做了很多优化工作避免了新的内存分配并更有效地在主机和 Wasm 模块之间共享内存。事实证明尤其是在 AssemblyScript 中分配新内存的速度非常慢因为 AssemblyScript 提供了一个易于使用的垃圾收集器它确保内存被正确清理。但它使用的是一个相对简单的算法每次需要分配新内存时都会增加大量时间。
因此我们做的一个主要优化就是创建一个固定长度的内存缓冲区作为传递数据的暂存空间而不是每次都重新分配整个缓冲区。以前的做法是每次都分配一个新的缓冲区把数据写进去然后让 Wasm 读取这个缓冲区中的数据。现在我们只需要写入已经分配好的缓冲区的一部分然后告诉 Wasm 从哪里读取。这样就不需要每次都分配新的内存速度快了很多。我们的主要工作就是围绕这些优化展开的。我可以继续讲但你有没有问题想问
Jonathan Norris: 我对 Go 方面的情况很好奇这些性能数据非常令人印象深刻。你们是怎么测量的因为你们是从 Go 运行时的角度测量的而不是 WebAssembly 项目。你们一开始用的是什么工具来进行这些测量
Adam Wootton: 是的我们实际上使用了很多不同的工具出于不同的原因。我之前提到的这些数字主要是通过运行 Go 的基准测试获得的测试的内容是尽可能快地评估变量使用单线程运行最后输出每个操作的时间。这就是我们最初获取数据的方式。
随着我们深入研究我们意识到还有更多因素需要考虑尤其是当你开始处理多线程时这对 Go 的 Web 服务器非常重要你不能让单线程成为所有处理的瓶颈。因此这改变了我们测量的方式。
除了测量每个操作的时间之外我们还深入研究了 Wasm 调用的实际时间以及这些调用中的哪些部分比较慢。这在 Go 端并不容易测量因为我们使用了 pprof 工具生成 CPU 配置文件并进行分析。从 Go 的角度来看WebAssembly 模块边界之后的一切都是一个黑盒。因此我们的 pprof 输出上显示了一个巨大的箱子时间在 20 到 30 微秒之间。我们想知道“这里面发生了什么我们该如何找出问题所在”最后我们发现 Node.js 对 WebAssembly 的原生支持非常好甚至可以输出 WebAssembly 调用的 CPU 性能信息精确到每次操作的具体执行情况。
因此我们把在 Go 上测试的同一个模块放到了我们的 Node SDK 中在那里运行基准测试并收集 CPU 配置文件。Chrome 浏览器有一个调试工具可以直接附加到 Node 进程上。通过这种方式我们得以捕获与 Go 上相同测试的 CPU 配置信息。这让我们能够看到“这是 WebAssembly 代码中的哪个具体调用比较慢”或者“我们应该把时间花在哪些优化上”。通过这样做我们又节省了 20 到 30 微秒的时间。我们发现了很多代码中不必要的内存分配、重复调用或者可以预先转换服务器发送过来的配置数据、以更高效的方式进行迭代处理这都带来了很大的启发。
这也是一次有趣的调查。然后我们还遇到了一些内存大小方面的问题比如“它分配了多少内存有没有内存泄漏”为了解决这个问题我们找到了一些工具它们可以插入 AssemblyScript 编译器详细输出当前堆上的内容以及分配了哪些内存。通过比较两个堆转储我们可以发现“这里可能有内存泄漏”或者“这个地方分配了太多的内存”然后开始深入研究这些问题。所以总体而言我们使用这些工具对这些问题进行深入挖掘的体验相当不错。
Jon Calhoun: 你提到使用 Node 来研究 WebAssembly并跟踪哪些部分耗时较长你觉得未来 WebAssembly 本身会有相关工具让你不必跨语言进行测试吗没有直接调用 WebAssembly 的其他方式吗
Jonathan Norris: 我认为 V8 运行时是目前最成熟的 WebAssembly 运行时因此它具备这些开发工具。而我相信 Code Alliance 团队的 Wasmtime 项目也在开发类似的输出功能支持他们所支持的各种运行时。但目前的通用建议是如果你想获得低级别的性能优化将它插入到支持 WebAssembly 的浏览器引擎中是获得低级别性能信息的最佳方式。Node 运行在 V8 上因此从服务器端使用来看它是最简单的方式。
Jon Calhoun: 当你们进行这些优化时发现其他公司有类似的做法吗你提到 WebAssembly 尚未被广泛采用是否有其他公司可以交流经验
Adam Wootton: 我们还没遇到过和我们做类似事情的公司即通过 WebAssembly 模块创建可重用的代码块用于 SDK 和服务器等不同场景。我相信肯定有其他人在做类似的事情只是我们目前还没遇到。如果有人在做请联系我们。但我之前提到过 AssemblyScript 社区对我们非常有帮助。我们加入了他们的 Discord 群组语言的创造者每天都在群里回答问题给了我们很多指引。没有他们的帮助我们不可能走到这一步。我们非常感激他们的帮助。不过确实有很多摸索和尝试的过程但现在比刚开始时好多了。我们对这些技术的理解比最初更深入了。
Brad Van Vugt: 是的。我也觉得大多数想要开发高性能 WebAssembly 代码库的团队可能会选择使用 C、Rust 等底层语言作为编译到 WebAssembly 的目标语言。如果你是从头开始一个新项目而不是像我们这样已有 TypeScript 代码库我肯定会推荐你从 C 或 Rust 这样的语言开始。这两个语言的社区在编译到 WebAssembly 方面比 TypeScript 更为成熟。
这就是我的建议。你也可以选择使用 Go。不过据我了解从 Go 到 WebAssembly 的转换效率似乎不如 Rust 和 C。它的效率大概和 AssemblyScript 差不多。所以你不会得到像 C 或 Rust 那样优化良好的代码尽管肯定有很多 Go 开发者在努力优化此事我相信它会随着时间的推移变得更好。
但如果你想做一些对延迟非常敏感的事情我还是建议从底层语言开始。我们自己也在朝着将代码迁移到更底层语言的方向发展以便能进行更直接的优化。因此未来几个月或几年内我们可能会逐渐转向这种方向。
Jon Calhoun: 我想确认一下… 我记得你说 WebAssembly 有垃圾收集器但你们没有使用它因为它在你们的场景中太慢了你们需要一个暂存区域。这是否导致了内存泄漏等问题
Adam Wootton: 这里有几个方面。首先目前 WebAssembly 本身还没有垃圾收集器虽然我知道他们正在提议一个标准化的垃圾收集器。目前垃圾收集器的实现取决于你使用的编译到 WebAssembly 的工具。在我们的例子中垃圾收集器是由 AssemblyScript 编译器实现的。最终我们发现当我们去掉所有其他可以优化的部分时垃圾收集器的实现成了主要的性能瓶颈。每次内存分配操作在性能分析中都显示为相对较慢的部分。
我们也做了一些有趣的工作调整了垃圾收集器算法中的一些变量尝试优化其运行频率和中断时间尽量平滑执行时间的波动。我们还在测量 p50 和 p99 的执行时间发现它们之间的差异很大这实际上也是垃圾收集问题。每当垃圾收集器打断执行时特定调用的执行时间会增加三到四倍我们需要尽量缩小这个差距。所以我们尝试调整垃圾收集器的参数看看能否减少这种差异。
至于内存泄漏问题… 我们遇到的一个有趣的情况促使我们使用了之前提到的工具该工具是 AssemblyScript 的一个插件它会分析堆中的内容告诉你哪些内存已经分配了。我们使用这个工具的输出来找出内存泄漏的位置。
有趣的是当我们使用这个工具时我们并没有看到新的内存分配或者堆内存的显著增加。但我们看到的是线性内存的增长在 WebAssembly 的 Wasmtime 里当线性内存不足时它会增加可用的内存通常是两倍的增长。
但我们发现线性内存在不断增长而堆内存却没有明显增加。我们最终发现这是我们使用的某个库中的一个 bug。这个库使用了 AssemblyScript 中的一个名为“非托管类”的概念它跳过了垃圾收集器但库并没有正确管理这些类的引用。因此垃圾收集器无法追踪它库本身也忘记了它们的存在导致大量内存被这些未管理的类占用了却从未被释放。经过调查我们与该库的作者合作修复了这个问题问题就消失了。
Jonathan Norris: 是的关于 WebAssembly 垃圾收集的背景信息目前垃圾收集是由 WebAssembly 运行时自行管理的。例如AssemblyScript 有自己的垃圾收集器如果你使用 Go 编译为 WebAssembly它也会自带一个垃圾收集器。不过有一个非常令人兴奋的提案允许将垃圾收集暴露给主机运行时。例如未来在 Go 中运行 Wasmtime 时Go 的原生垃圾收集器可以管理 WebAssembly 中的所有指针和引用。如果是在浏览器或 Node 中运行V8 的垃圾收集器也可以管理这些引用。这将比当前在 WebAssembly 中嵌入一个垃圾收集器高效得多。我们对此提案非常关注未来可能会成为这一技术的早期采用者。
Jon Calhoun: 我猜如果有人从 C 或 C 转到 WebAssembly他们仍然需要自己管理内存。这是否也是为什么 C 在 WebAssembly 性能方面比较领先的原因之一
Jonathan Norris: 是的没错。如果你自己管理内存那么你就不需要承受垃圾收集的开销确实会得到更高性能的 WebAssembly 代码库。但你也得自己负责内存管理…
Brad Van Vugt: 我想问一下并发模型的差异。因为选择在服务器端使用 Go 的一个大理由是并发和多线程支持。而在 WebAssembly 上构建的核心代码显然会有一些权衡。你们是如何处理的你认为未来如何使其更高效
Adam Wootton: 是的目前 WebAssembly 的多线程支持还没有完全实现AssemblyScript 也不支持任何形式的多线程。因此为了安全地调用我们的 WebAssembly 模块我们基本上在每次调用时都加了一个互斥锁以确保不会因为多个 goroutine 同时访问而破坏内存状态。问题是这显然会为任何试图同时处理数千个请求的 Web 服务器创建一个单一的瓶颈。每次它请求变量值WebAssembly 模块都会说“抱歉现在在处理其他请求。”
我们在 SDK 中的解决方案是创建多个 WebAssembly 模块实例并在它们之间进行调度。所以当多线程支持最终实现时我们肯定会集成它。但在此之前我们采用了“对象池”的方案每次需要调用时借用一个 WebAssembly 模块完成工作后再把它归还给池子。这个 SDK 允许你配置对象池的大小默认情况下是 CPU 核心数。每次 SDK 请求变量值时都会借用一个 WebAssembly 模块执行任务后再归还。
这是我们的解决方案它基本上解锁了更好的并发性能。不过也有一些挑战例如 WebAssembly 需要保持最新的服务器配置因此我们必须确保池中每个 WebAssembly 实例都保持最新配置。我们设置了一些机制从池中取出部分对象进行后台更新更新完成后再重新投入使用。这需要一些调度但总体上解决方案效果不错。
Jon Calhoun: 这个管理机制是否需要在每个 SDK 中单独实现比如在编写 Go SDK 时要设置它在编写 Rust SDK 时也要设置
Adam Wootton: 是的确实是与语言相关的。其实这也是 WebAssembly 的初衷之一让我们可以轻松编写跨平台的 SDK。但随着我们深入性能优化我们发现需要为每个平台编写更多特定的代码。例如之前提到的 Protobuf 序列化。为了在 WebAssembly 边界传递数据我们从 JSON 转换为 Protobuf。要实现 Protobuf 序列化和反序列化我们需要在每个 SDK 中实现或使用现成的库。
我们保留了一些旧接口因此 Wasm 模块仍然可以使用 JSON也不需要多线程支持具体取决于平台。在一些平台上性能已经足够好了而在 Go 上我们有更高的性能需求。
Jonathan Norris: 这是关键点… 在 99% 的情况下Wasm 代码的单线程性能已经非常好了互斥锁几乎不会影响性能。但对于我们这种特定的高负载 CDN 服务器场景这种优化确实降低了 p50 和 p99 的执行时间。对于大多数用户Wasm 代码的单线程性能已经足够好不会有明显的差异。
Jon Calhoun好了现在是时候进入我们不受欢迎的意见环节了。意见不一定要与技术相关只要是你认为是个不受欢迎的观点就行。我们会把这个观点放到 Twitter 上做个投票让我们的听众决定他们是否认为它真的不受欢迎。那么有人愿意先来吗
Jonathan Norris好吧我来吧。我的不受欢迎观点是到 2030 年WebAssembly 运行时将取代基于容器的运行时。WebAssembly 的优势在于其严格的安全模型、非常快的启动时间、边缘计算的可扩展性、更小的占用空间以及跨环境的可移植性这些都将推动从基于容器的运行时例如 Kubernetes 和边缘工作负载向 WebAssembly 的转变。WebAssembly 社区内有很多力量在推动这一转变。
Brad Van Vugt你认为现在实现这一目标的最大障碍是什么
Jonathan Norris这是个好问题……我认为可能是语言支持、性能分析和工具支持。正如我们今天讨论的那样如何让 WebAssembly 更容易优化和分析是一个大问题。还有标准化……WebAssembly 即将迎来很多令人兴奋的变化。我们已经讨论了一些比如多线程支持和原生垃圾回收支持。
其中一个即将到来的重大变化叫做组件模型component model它标准化了多个 WebAssembly 组件之间的通信使它们能够相互交互并使你的代码更加模块化更容易拆分成小块。因此社区正在为此进行大量工作推动用这种方式取代容器特别是在 Kubernetes 和边缘工作负载中。
是的我认为这些是关键点如果 WebAssembly 社区能够实现这些即将到来的重大变化比如组件模型、多线程、垃圾回收支持等那么我们就将走上这条路并且在未来几年内我们会看到一些围绕这个领域的新公司崛起。
Brad Van Vugt我觉得有趣的是Jonathan我们经常谈论这个问题而我认为我的不受欢迎观点恰好相反……也许在时间上可能有差异但我认为要实现这一点的工作量非常大。你认为 AssemblyScript 是其中的关键环节吗作为一种核心的原生切入点
Jonathan Norris我认为一个更易接近的高级语言作为切入点非常重要。我认为这是 WebAssembly 目前面临的挑战之一最好的开发环境是底层环境比如使用 Rust 或 C。实际上围绕在 WebAssembly 中运行 JavaScript 或 TypeScript 有不少动力但这是通过将 SpiderMonkeyFirefox 的 JavaScript 引擎打包到 WebAssembly 运行时中实现的。他们已经能够在几兆字节的体积内让它运行。所以基本上你可以在 WebAssembly 中运行完整的 SpiderMonkey 运行时并执行你的 JavaScript 或编译后的 TypeScript 代码……这是许多 Wasm 云或 Wasm 边缘公司的重要切入点之一。但我会说找到一个在 Wasm 中高效执行的高级语言可能是实现这一目标的最大障碍之一。
Kris Brandow从另一个角度看我也在想你是否看到……嗯我应该这样说有很多来自虚拟机VM和管理程序hypervisor的压力它们变得非常快比如 Firecracker 等等……你是否看到这些技术可能会融合以便你可以获得虚拟机的安全性以及 Wasm 的速度和其他优势
Jonathan Norris 是的。不要误会虚拟机经过多年的发展已经非常优秀了我们依赖它们来管理许多大规模系统……但我认为容器的体积和 WebAssembly 之间存在数量级的差异。你可以优化容器的大小让它们变得相对较小比如十几兆字节……但 WebAssembly 从核心设计上就比这更便携你讨论的是几十千字节而不是几十兆字节。而启动时间可以以微秒为单位计算而不是毫秒、几十毫秒甚至几秒。所以通过使用 WebAssembly性能上的数量级变化是显而易见的我认为很多容器化系统很难与之匹敌。
你可以想象一个在边缘大规模运行的平台比如我们的使用场景。我们有很多 SDK 访问我们的边缘 API。我们的一些客户比如大型移动应用可能会发送推送通知并且会有成千上万甚至上百万的人同时打开他们的应用当体育比分或重要新闻出现在他们的手机上时他们会同时打开应用。在这些时刻我们看到的流量激增是我们平时流量的 100 倍这些流量会在瞬间涌向我们的边缘端点。而因为我们使用这些边缘平台它们能够在毫秒内启动数千个 Wasm 和边缘运行时来处理这些流量。使用虚拟机也可以做到这一点但在这个工具链中有更多的延迟。
所以我认为 WebAssembly 不仅拥有非常严格的安全模型其启动时间、模块的小体积也确实具有强大的优势。在某些使用场景中它非常有意义。我不会说它适用于所有场景显然不会。但对于那些高性能、对延迟敏感的应用场景比如向全球的移动应用或网页应用发布功能标志WebAssembly 在我们这个使用场景中显得非常适用。
Jon Calhoun所以这意味着在这种情况下……我的看法是目前使用容器比如 Docker的解决方案可能稍微慢一些但它们适用于 90% 的使用场景这只是一个随意的数字但它们确实适用于一大部分场景。而你所说的 WebAssembly 替代方案因为速度等优势可能有一大群人其实并不太在意这些。所以我猜想如果 WebAssembly 要取代 Docker必须变得和 Docker 一样容易使用。我觉得只有这样才能实现。你觉得现在 WebAssembly 和 Docker 一样容易使用吗
Jonathan Norris哦肯定还没有那么容易。我认为在开发者工具方面还有很多工作要做才能让它变得容易。我们一直在使用 Cloudflare Workers对于边缘运行时它们确实让部署变得超级简单它们在这方面做得很好。但我认为它的真正好处在于安全性方面。通过 WASI 接口WebAssembly 模块对其访问权限的控制比虚拟机要严格得多。所以对于那些非常注重安全的公司我认为它在某些任务关键型模块中会有很大的价值。
此外还有很多成本方面的好处。为什么在 Cloudflare Workers、Fastly 或 Netlify 等边缘运行时中运行工作负载要比在 AWS Lambda 这样的环境中便宜得多原因之一是启动和关闭时间以及它们管理的二进制文件的大小都小得多。这些边缘运行时可以在毫秒甚至更短的时间内启动你的代码而 Lambda 等基于容器的边缘服务需要更长时间启动它们的内存占用也更大。因此这里的成本差异可能非常大。
我们自己通过将工作负载迁移到这些边缘运行时节省了大量成本。我们不仅构建 SDK还在边缘运行高规模的 API。拥有小型、便携、快速的运行时可以在全球各地执行带来了巨大的成本优势。
Jon Calhoun这很有道理。好的Adam、Brad 或 Kris你们中有谁愿意分享一个不受欢迎的观点吗好像没有。大家都不敢发表意见。
Kris Brandow我可以想出一个观点……
Brad Van Vugt是的我可以说很多但我不知道……[笑声] 我不知道是否值得讨论这些。
Kris Brandow这不就是这个环节的目的吗说点有争议的东西。
Jon Calhoun我记得我们之前有个挺有趣的观点我得去看看是否已经在 Twitter 上发布了。有一次我和 Mat 还有 Matthew Boyle 聊天他是《Golang 领域驱动设计》一书的作者……他的不受欢迎观点是你应该可以把笔记本电脑带进电影院并在看电影时使用。我还是觉得这是我们最不受欢迎的观点之一。
Brad Van Vugt我有很多带笔记本电脑进电影院的故事因为我当时要值班每次进电影院时都会接到电话。我们第一家公司刚开始时我连续三次进电影院时都接到了电话。
Jon Calhoun所以你可能同意他的观点这样你就不用离开电影院了。
Brad Van Vugt我完全同意他。
Jonathan Norris我同意我应该被允许这么做但我不知道其他人是否应该被允许这么做。[笑声]
Adam Wootton幸运的是现在我们切换到边缘工作者后你在看电影时不会再经常接到电话了。
Jonathan Norris确实如此确实如此。
Jon Calhoun好吧如果没人再想分享什么我就播放结束音乐我们结束这一期节目。大家觉得怎么样
Kris Brandow我可以再想一个不受欢迎的观点……让我想想。
Jon Calhoun随你决定Kris……
Brad Van VugtAdam我觉得你有很多不受欢迎的观点。
Adam Wootton好吧……我认为 Kubernetes 在技术行业中被过度使用了。我觉得有很多人根本不需要 Kubernetes却在用它其实可以用更简单的方式来部署服务器。我们正在使用 Kubernetes但回头看我觉得我们不应该使用 Kubernetes。这可能是个不受欢迎的观点……虽然我也看到网上有一些人开始意识到这一点了。
Kris Brandow我觉得这个观点有点分裂。要么你是被烧过的人所以你觉得这个观点很受欢迎要么你还在迷恋 Kubernetes所以你觉得这个观点很不受欢迎。
Jon Calhoun就像在 Go 这种语言中使用第三方库或框架。有些人坚决反对而另一些人则会说“对我来说用着挺好的所以我没问题。”
Brad Van Vugt上周我去了在阿姆斯特丹举行的 KubeCon我得说企业界尤其是那些拥有数百个服务或微服务并运行在 Kubernetes 上的大型企业对此非常热情。对于这些企业来说确实很有意义围绕 Kubernetes 也有很多工具。但如果你是一家小公司可能很多工作负载都在边缘运行或者像我们一样主要通过 SDK 运行并且只需要运行少量服务那么 Kubernetes 可能有点大材小用了反而会导致更多的停机时间而不是提高团队的生产力……我觉得我们目前的经历就是这样。
Adam Wootton是的一切都很好直到你第一次不得不深入 Kube 系统命名空间去搞清楚哪个内部 pod 出了问题或者集群出了什么问题。
Jon Calhoun我完全同意这个观点可能更好的做法是教会大家还有其他部署方式并确保大家知道这些方式的存在而不是让他们觉得 Kubernetes 是“我们最终都会用的东西”。因为我确实见过很多小项目刚刚起步的时候他们就已经在用 Kubernetes 了而实际上他们可能还没有十个用户你会觉得“我不确定这是否真的需要。”
Adam Wootton是的我觉得很多人并不了解如何用更简单的方式让你的代码在服务器上运行。你并不总是需要构建一个完整的编排系统来让某些东西运行。
Jonathan Norris是啊让 Heroku 回来吧……
Adam Wootton我喜欢 HerokuHeroku 太棒了。我在很多黑客松上都用过它……
Jon CalhounHeroku 确实很棒直到你需要真正扩展的时候你的账单就会飙升。
Adam Wootton哦是的。但同样它确实是一个可以快速上手的工具。像我有一些代码只需要它运行起来。我只需要一个人们可以访问的端点。对于这种需求它是个很棒的工具这也是为什么我在黑客松上用它这是让代码快速部署的最好方式。
Brad Van Vugt我觉得当 Heroku 流行时没有人说它很好用而现在它快退出历史舞台了大家却对它充满了怀旧之情。我记得那些 Heroku 的美好时光……但当它刚出来时没人站出来支持它。
Jonathan Norris谢谢你让我觉得自己老了Brad……干得好。[笑声]
Jon Calhoun我对此感受复杂如果是黑客松项目我当时确实经常用它。但当它变成一个需要付费的产品或者我需要稍微扩展一下时我立刻会想“我得把我的东西迁移到其他更便宜的地方。”或者在一些创业孵化器的情况下你会得到一些 Heroku 的资金支持……我不记得具体有多少了但那是一个非常高的数额可能有 10 万美元的 Heroku 代金券。所以在这些情况下你并不在意因为在一年内很难花掉 10 万美元……所以你根本不在乎。但如果是一个实际的付费业务模式那就很难让我说“是的我真的怀念每月花 40 美元去维护一个服务 10 个人的应用。”
Jonathan Norris或者每月花 1500 美元去维护一个数据库……
Jon Calhoun实际上能用的
Jonathan Norris……冗余的数据库。
Brad Van Vugt这就是为什么我喜欢所有这些边缘运行时的按使用量计费模式。只为你实际使用的部分付费我觉得这才是未来的方向。
Adam Wootton是啊我们有一次一个月的流量账单好像只有 10 美元对吧
Jonathan Norris哦对于某些服务是的。对于某些服务。当然不是我们的主要平台。
Adam Wootton不是主要平台是的。但对于数千万次请求来说账单大概只有 10 美元差不多是这样。
Brad Van Vugt是啊现在你可以从一些服务中免费获得大量请求。
Jon Calhoun好吧Kris你有想分享的东西吗
Kris Brandow是的我想我有一个稍微……算是稍微有点火药味的观点……但我认为我们现在做的所有 AI 相关的事情无论是 ChatGPT、Copilot 还是 Midjourney都是去年的 NFT或者是之前的 3D 打印机甚至是很久前的 Segway。这些技术并不会完全消失但它们会逐渐转向更加细分的市场而不会实现大家大肆鼓吹的那些功能。3D 打印机是个很好的例子。3D 打印机很棒确实很出色很多地方都在用它。但十年前人们说“每个大学生都会在宿舍里拥有一台 3D 打印机他们会打印自己需要的一切”但事实并非如此。
去年我们都在讨论 NFT大家说“NFT 将彻底改变一切”但实际上并没有。所以我觉得 AI 现在也处于类似的炒作阶段。我个人会很高兴看到这股热潮过去然后我们可以进入一个真正使用 AI 的阶段而不是炒作它的阶段。但我想说的是现在那些声称我们离通用人工智能越来越近的人因为我们有了这些大型语言模型我觉得他们是在异想天开。热潮会消退。我本想说六个月但感觉有点过于激进了。
Jonathan Norris 你是在暗示风险投资推特圈的人不知道他们在说什么吗
Kris Brandow是的。[笑声] 我说过这是个有火药味的观点
Jonathan Norris确实有点火药味我同意你所说的高层次观点AI 这个词有点误导。我不认为这些大型语言模型已经达到了通用人工智能的水平但它们非常有用。AI 热潮和去年 NFT 的骗局之间有很大不同。ChatGPT 真的能带来实际的价值。我们内部也在用它Adam 可以再说一个小时我们如何用 ChatGPT 加速了很多工作。作为开发者至少对我来说我从来不是最好的 Bash 编程人员或 SQL 编程人员但现在我可以在 ChatGPT 中输入“嘿帮我写个 SQL 查询做这个事情。这是表结构搞定它。” 它就会去做而且大多数时候都很准确。如果它错了你只需把错误代码粘贴回 ChatGPT它会根据错误代码重写查询并修正。这真的让我在过去几个月中大大加快了开发速度。
Kris Brandow是的……我觉得 NFT 的例子也很好分布式账本可以用来记录物品的流转过程追踪物品的所有权链条这个想法非常有趣但也非常小众。对于我们这些软件工程师来说这并不是我们现在特别关心的事情。但在某些领域比如葡萄酒或艺术收藏这可能会非常有趣。我觉得 ChatGPT 的一个应用场景是软件工程领域在这个领域当它出错时我们能很清楚地知道它出错了。
所以现在有些事情让我有点烦这也是我为什么会提出这个不受欢迎的观点。当人们说“哦大型语言模型产生了幻觉”我心想“它没有幻觉它只是生成了一个统计上正确但实际上错误的结果。” 就像自动纠错功能出错一样它只是出错了它并没有做任何不同的事情。但人们只是在以不同的方式解读它。所以我觉得在我们知道正确答案的领域比如说我们知道正确答案应该是什么样子AI 是可以用的。但在我们不知道的时候它可能会非常危险。
Jonathan Norris我觉得这和自动驾驶有些类似。所有关于自动驾驶汽车的炒作……我们还没有接近那种完全自动驾驶的汽车。我住在多伦多……在冬天开车的时候路上有积雪我们还远远没有达到自动驾驶的水平。但我们已经到了每辆新车---甚至是便宜的丰田车---都配备了非常好的车道保持功能这在高速公路上表现非常出色只要天气好。这就是我对 AI 的看法。也许我们在未来 20 年到 50 年内都无法实现完全自动驾驶的汽车但我们现在确实看到了逐步的改进我觉得 AI 也是类似的。
Kris Brandow嗯你已经同意我的观点了。[笑声]
Jonathan Norris我确实有点同意了。
Jon Calhoun我觉得问题在于如何看待它……如果你期待 AI 能够永远 100% 准确并完美执行所有任务我觉得任何这样想的人都会失望因为要做到这一点真的非常难。自动驾驶汽车也是一样。但我认为有些场景不需要 100% 的准确性只要它在某些特定场景中表现得非常出色就足够了。自动驾驶汽车就是一个例子如果我有一辆车它只会在高速公路上自动驾驶不需要在城市中处理复杂的情况这已经比我现在的状况要好得多了。
Jonathan Norris 我们已经非常接近这个目标了。
Jon Calhoun是啊所以它不需要完美。它可以跳过所有其他的边缘情况只要能在几个核心场景中表现得非常好就行。我觉得我们可以朝这些方向努力但问题在于人们脑海中总有一个“我们正在朝完美自动驾驶技术前进”的想法。对于 AI 来说人们可能会期待 AI 能够 100% 准确从不犯错……我觉得那些期待这种结果的人会失望。
但我想说ChatGPT 和其他类似工具让我感到满意的一点是它让很多非技术人员看到了他们可以用计算机解决生活中琐碎问题的潜力。对于开发者来说我们早就知道很多事情可以被轻松解决……就像我看着别人用 ChatGPT 做的事我会觉得“你其实可以不用 ChatGPT 也能轻松做到这些。” 但他们只是之前不知道怎么做现在他们可以利用这个工具这很好。我甚至在想如果现在发布了 Clippy 这样的东西它可能永远不会消失。而当年发布时……
Adam Wootton微软现在其实就是在重新整合类似 Clippy 的东西到 Office 套件中或者他们正在添加一个聊天界面。
Jon Calhoun我倒希望是 Clippy 这个形象重新出现。
Adam Wootton我相信有人会做一个插件把图标换成 Clippy……但我觉得这是个“最后 10%”的问题。自动驾驶和 AI 的区别在于对于自动驾驶你之前提到的完美的车道保持功能在高速公路上非常实用今天就已经很有用了。但问题是如果你想让它在城市街道上完全自动驾驶你仍然需要注意道路情况。所以车道保持之外的任何功能在没有完全实现之前并没有那么实用……因为即使它在城市中大部分时间能自动驾驶这对司机也没有帮助因为你还是得把手放在方向盘上还是得保持注意力。所以它并不真正减少司机的负担更多的是一个玩具。
但 AI 即使只完成了 90%你已经可以用它做很多实用的事情了。我觉得现在更多的是用户体验的问题。我喜欢刷 Twitter看看人们如何用这些工具想出新颖有趣的点子。很多人可能根本不会想到去那样做。但这并不是问题因为再过五年我们的大多数软件可能都会在后台使用这些技术提供现在人们用 ChatGPT 实现的那些功能届时界面会更好你不会需要解释它该做什么它会自动明白该怎么做。所以我觉得这一点非常令人兴奋看到它将如何无缝地融入现有软件中。
Kris Brandow是的。我一直觉得这些大型语言模型有点像高级编译器如果你不知道它们在做什么它们看起来就像魔法……但实际上编译器在某种程度上确实也是魔法。你输入了东西然后得到了结果你会觉得“我不知道这是怎么发生的。” 但当你了解它所用的基础组件时你会发现“哦原来如此我能理解这并不是超出理解的事情。” 但当你把规模放大时它确实会变得很复杂因为人类不擅长处理大数字。就像经典的例子“十亿美元和一百万美元的区别就是十亿美元。” 当你这样说时人们会觉得“这听起来不对。” 但如果你说“一千美元和一美元的区别是一千美元。” 人们会说“哦当然了。”
所以当你面对大量东西时无论是编译器中的大量编译指令还是大型语言模型中的大量权重它开始变得有趣你可以应用它。但我觉得这仍然是在小众领域中的应用比如“哦这些是我们可以用这项技术做的很酷很有趣的事情。”
也许更有火药味的观点是无论是自动驾驶还是通用人工智能我们永远也无法真正实现这些目标但继续追求它们仍然是好的因为所有的副产品对人类生活非常有用并能增强人类的生活。
Adam Wootton我听到很多人说如果我们不能实现通用人工智能那我们也无法实现自动驾驶。[笑声]
Kris Brandow我觉得有很多理由可能让我们永远无法实现自动驾驶……我不知道也许未来我们根本不需要汽车。也许我们会把公共交通做到极致再也不需要开车了。
Jonathan Norris哦千万别让我谈公共交通……我可以再讲一个小时。[笑声]
Adam Wootton多伦多刚开始建造市中心的第三条地铁线这可是 50 年后的事情了。[笑]
Jon Calhoun我住在美国的乡村所以公共交通在这里根本不存在。我住的这个小镇有两辆出租车而且不一定总在运营。你需要打电话预约他们不会随叫随到。Lyft 和 Uber 在我这里都不存在。
Kris Brandow你知道的总有些希望的曙光……我看过一个很酷的视频讲的是瑞士的铁路系统。视频里有一个随机的滑雪缆车和咖啡馆我记得是关于一些徒步路线的视频里说“哦我们每 30 分钟就有一趟火车全天候运营。” 我想“哦原来农村火车也可以这样运行好吧……” 但对于美国人来说尤其是生活在农村或郊区的人来说想象高质量的公共交通确实很难。
Jon Calhoun我觉得有时候……他们需要亲身体验这些好处才能真正感受到。有一次……我忘记是哪个城市了……好像是田纳西州和另一个城市他们在讨论建设一条火车线路可以让你在几个小时内从一个城市到另一个城市……在一个播客上我听到有人在谈论这个他们说“搞这个有什么意义” 我想“是啊确实没什么用直到你突然发现你可以轻松地去另一个城市然后你会发现自己比以前更多地做这些事因为它很方便。” 而如果你得开车八个小时或者你得飞过去面对所有与飞行相关的麻烦事你可能不会经常做这些事。但坐火车大多数时候是非常容易的。
Adam Wootton是的我记得当我第一次去伦敦时发现我可以坐火车在两小时内到达巴黎时我简直不敢相信。我想“等等我本来计划是去伦敦旅游但我也可以顺便去巴黎而且只需要坐火车就能到。” 这太疯狂了。
Jon Calhoun好吧我觉得差不多了。我来放结束音乐然后停止录音。谢谢大家的参与。Jonathan、Adam、Brad感谢你们的加入。Kris谢谢你帮助我主持节目。
Kris Brandow当然没问题。
Jonathan Norris谢谢你邀请我们。
Brad Van Vugt谢谢你邀请我们。
