“告别 8 万行 C+代码,我用 4 千行 C 代码就搞定了!”

摘要:这一次,Zig 要彻底告别 C++ 了。

链接:https://ziglang.org/news/goodbye-cpp/

声明:本文为 CSDN 翻译,未经允许禁止转载。

作者 | Andrew Kelley       

译者 | 弯月   责编 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

在此次变更之前,Zig 代码库由两个编译器组成:

旧编译器:总共包含 8 万行 C++ 代码,加上新编译器共享 Zig 代码。

新编译器:总共包含 25 万行 Zig 代码。

新编译器的速度更快,使用的内存更少,并得到了积极的维护和增强。同时,没有人想碰旧编译器,但是通过源代码构建新编译器时需要用到旧编译器。

这意味着,新的 Zig 语言特性必须实现两次:在新代码库中实现一次,然后在旧代码库中再实现一次——这是一个巨大的痛点,尤其这两个编译器的设计早已大相径庭。

此外,用 C++ 实现的 Zig 最初使用的策略与 D 编译器相同:在进程退出之前不释放任何内存。但随着编译时执行代码成为该语言的标志性功能之一,加之使用同一个编译单元来处理一切,项目的规模越来越大,这个设计决策就有点不合时宜了。

解决方案

这个问题很有趣,有很多解决方案,但每一种都有一定的弊端。在搞清楚问题之后,我们就各种可能性展开了快速的头脑风暴会议,每个提议都有自己的优缺点。

放弃自我编译

Odin 就采用了这种方法。

这个方法可以解决整个问题,但缺点是我们必须放弃 Zig,转而使用 C。我不同意,因为 Zig 带来的改进太诱人了,我不想放弃:例如,我们使用的一些面向数据的设计技术无法通过 C/C++ 实现。

使用旧版本的编译器

这是 Rust 和许多其他语言采用的方法。

这种方法的一大缺点是,根据源代码构建任何提交都需要经过复杂的操作。例如,假设你尝试执行 git bisect,有时 git 会检出一个旧版本的提交,但脚本无法利用这些源代码构建,因为构建编译器的二进制文件不是正确版本。当然,这个问题并不是无法解决,但势必会给开发人员带来许多不必要的麻烦。

此外,构建编译器也会受到目标平台上已有二进制文件的限制。例如,假设没有 riscv64 版的编译器,就无法在 riscv64 硬件上利用源代码构建。

因此关键问题在于,这种方法无法充分支持能够在任何系统上构建任何提交的需求。

将编译器编译成 C 代码

这是 Nim 采用的方法。

与前面的策略相比,这种方法的好处是可以将生成的 C 代码提交至源代码控制,比较方便,但如果这些 C 代码只能用于特定平台,实际效果也是一样的。

我不太清楚怎样才能生成不依赖于平台的 C 代码(像 Nim 那样),但我看到他们的描述中说:“支持的 CPU/OS 组合比旧的 csources 代码库更多”。这意味着,尽管他们的代码可以在许多 CPU/OS 的组合上编译,但这并不一定表示这些 C 代码具有可移植性。此外,这些代码与主编译器分别保存在不同的代码库中,所以并不能解决前一种策略遇到的问题。

我探索了这种可能性,发现生成的 C 代码不仅只能用于特定平台,而且代码量非常大。我们的编译器会生成一个 80 MiB 的 C 文件。虽然我们可以通过 C 后端增强来改进,但与其接受如此大规模的扩张,还不如直接将二进制文件提交到 Git 代码库。

将编译器编译成 C 代码,之后直接维护 C 代码

这种方法我从多年前就想试试,最近终于开始研究了一下。很明显的一大缺点是,清理自动生成的 C 代码非常困难,而且依然需要维护两种编译器实现,容易打击贡献者的积极性——谁会愿意用 Zig 和 C 重复两次相同的工作?

将编译器编译成简单的虚拟机

有一次,在讨论编译器自举时,Drew DeVault 提到了 OCaml 的策略。于是我有了一个想法:可以建立一个自举专用的后端。

不过我认为 Zig 和 OCaml 之间还有一些差异。Zig 只有一个虚拟机平台,它是跨平台的,可以通过 LLVM 进行优化——这就是 WebAssembly,使用 WASI 作为操作系统抽象层。

探索思路

主要思路是,利用一个非常小的 wasm 二进制作为 stage1 内核,提交到源代码控制,这样就可以用它来编译源代码中的任何提交。我们提供了一个 C 编写的 WASI 解释器,然后用它将 Zig 编译器代码编译成 C 代码。之后用系统的 C 编译器对 C 代码进行编译和连接,生成 stage2 二进制文件。接着,stage2 二进制文件就可以通过反复的 zip build 从源代码进行构建。

wasm 二进制文件是通过 zig build update-zig1 生成的,后者使用了 LLVM 后端来生成一个针对 wasm32-wasi 平台、generic+bulk_memory CPU 的 ReleaseSmall 二进制文件。该二进制文件中 C 之外的所有后端都是禁用的,这样产生的文件仅有 2.6MiB。然后再通过 wasm-opt -Oz --enable-bulk-memory 进行优化,压缩到 2.4MiB。最后,用 zstd 进一步压缩至 637KB。其中还包括了 zstd 解码器(用 C 实现),但这是值得的,因为 zstd 的实现基本不会改变,而且它每次都能给 wasm 二进制文件节省下 1.8MiB。

因此,我们用 4 千行可移植的 C 代码替换了原本 8 万行的 C++ 代码。这些代码仅使用了标准 libc 函数,且不依赖于任何 POSIX 的头文件,也不依赖于 windows.h。操作系统互操作层完全抽象到了几个 WASI 函数中,由 WASI 解释器负责实现:

为了让 Zig 编译器把自己编译成 C,只需要使用这些系统调用。

Jacob Young和我一起,在andrewrk/zig-wasi的基础上完成了这个 WebAssembly/WASI 解释器。我用 Zig 建立了初版,借助 Zig 丰富的标准库和安全机制探索了这个思路。这个解释器不会提前解码 wasm 模块,而是直接使用文件偏移量作为程序计数器。虽然它能正常工作,但太慢了,对编译器进行解释执行需要好几个小时,而用原生机器码只需大约 5 秒钟。

因此,Jacob 改善了该项目,引入了另一个指令集和更多的优化,还有一些其他技巧,将性能提升到了可接受的程度。同时,我将 Zig 代码转成了纯 C。

我们一起努力了大约两个星期,互相将对方的代码合并到自己的分支中,交流心得、分享成功的喜悦。我非常感谢 Jacob 在这个项目上的努力,特别是他一丝不苟地改进 Zig 的 C 后端,才让这个项目得以成功。

在概念得到证实后,Jacob 意识到,将 WebAssembly 转成 C,要比直接解释执行更快。这实际上就是 JIT 编译,但更大的好消息是,我们的自举工具实际上是系统的 C 编译器。

WebAssembly Binary Toolkit 项目里有一个 wasm2c 工具,但我们并没有移植或分叉——Jacob 从零开始创建了一个 wasm2c 的实现。这个实现没有考虑通用性,只包含了在编译器编译自己时需要调用的系统调用。

所以,这个版本的 wasm2c 只有 4 千行代码,也不依赖 C++,采用了更简洁的方式,没有实现任何沙盒、安全特性等。

新的构建过程

下面是新的构建过程:

总结:

使用系统 C 编译器编译 zig-wasm2.c;

使用 zig-wasm2.c 将 zig1.wasm.zst 转换成 zig1.c;

使用系统 C 编译器编译 zig1.c;

a.注意 zig1 只启用了 C 后端。

使用 zig1 将 Zig 编译器编译成 zig2.c;

使用系统 C 编译器编译 zig2.c;

a.这个编译器的逻辑是正确的,但它的机器码是由系统 C 编译器优化的,而不是它自己优化的。所以我们继续进行第六步,得到一个自我编译后的性能特性。

zig2 build(使用旧版本 Zig 编译 Zig 的标准构建流程);

如果用最后一步产生的结果再次编译 Zig,会得到同样的字节码。也就是说,zig3、zig4 是完全相同的。所以整个过程结束,最后得到的二进制文件可以去掉后缀,直接命名为 zig。

wasm 二进制的更新仅限于有重大更新,或新功能影响到编译器构建自身的时候。例如,编译器中的 bug 修复不会影响编译器编译自身,因此可以忽略。但如果 Zig 编译自身时必须修复该 bug,那么就需要更新 wasm 二进制。与之相似,当语言改变、编译器需要使用新功能来编译自身时,就要更新 wasm 二进制文件。

更新stage1/zig1.wasm.zst的方法如下:

性能

我收集了两个性能数据:

数据#1:使用make -j8 install 从源代码编译,配置为-DCMAKE_BUILD_TYPE=Debug:

数据#2:使用ninja install从源代码编译,配置为-DCMAKE_BUILD_TYPE=Release:

其中最关键的是构建时内存的需求量。一个只有 4~8GiB 的 RAM 能否编译 Zig 是非常重要的,这决定了是否可以用 GitHub 认证的 Action。

未来的计划

有一点我要承认,尽管此次改动大获全胜,但还是有一个地方退步了,即能否在固定次数内实现 Zig 的自举。

在这之前,从源代码开始的构建过程没有涉及任何二进制块,除了系统的 C/C++ 编译器之外。但此次改动之后,它使用了 WebAssembly 的二进制,这并不是源代码,而是一个构建结果,有些人可能非常看重这一点。

这是需要付出的代价,但我认为这些代价是值得的。考虑到官方语言规格以及 Zig 越来越受欢迎的现状,我们会看到更多的第三方项目开始用 C 来实现 Zig。

我愿把此次改动之前的版本标记为 1.0,且此次改动也并不在 Zig 软件基金会的计划内。当然,事情可能会改变,这只是目前的计划。

此外,此次改动还去掉了 -fstage1 标志,这个标志可以让 Zig 用户选择旧版本编译器来代替新版本——这是使用异步函数的唯一方法,而异步函数功能在新的编译器中还没有实现。

我建议需要使用 -fstage1 标志的用户继续使用 0.10.0,当 0.10.1 发布后进行升级,最终升级到 0.11.0,该版本将会支持异步函数。注意 Zig 采用语义版本号,因此本文中所说的一切都不会进入 0.10.1 发布,。0.10.1 只会包含 master 分支上的 bug 修复。

语言的发展

从更积极的方面来看,此次改动意味着所有计划中的语言改动都可以更快地进行。当我们脱离了旧代码的束缚,Zig 0.11.0 的发布迭代会更快。

有了这个改动,我们就可以像试用标准库那样,立即试用语言上的新改动。

在这个改动合并到主分支时,标签“stage1”下已经有 650 个问题,而这些问题所针对的代码都可以删掉了!所以,理论上我们可以立即关闭这些问题,不过我要求关闭这些问题时必须编写相应的测试用例,或者证明相应的部分已经有测试覆盖了。也许这需要付出更多的努力,但这正是我们当前的工作。

最新资讯

文档百科

CopyRight © 2000~2023 一和一学习网 Inc.All Rights Reserved.
一和一学习网:让父母和孩子一起爱上学习