实现自托管后,Zig 的下一步是什么?
随着 11 月 1 日 Zig v0.10.0 版本的发布,其新的自托管编译器(self-hosted compiler)也将同步推出。“尽管自托管编译器现已实现,但仍有更多的工作要做。与此同时,更多令人兴奋的功能的大门已经打开,比如 Zig 的官方包管理器。”
Zig 项目的下一步计划包括:
性能改进
与旧的 C++ implementation(也称为 bootstrap compiler)相比,新的自托管编译器将内存使用量减少了 3 倍。
例如,构建编译器本身过去需要 9.6GB 的 RAM,而现在只需要2.8GB。现在可以在 32 位系统和资源有限的机器(如 CI 运行器)上构建 Zig。此改进解决了一些用户无法在其设备上构建 Zig 的问题。
而内存效率的提高在很大程度上也要归功于在自托管编译器设计中采用的面向数据的编程技术。
自定义后端
虽然成功的节省了内存,但自托管编译器并没有比旧的编译器快(作为一个 data point,自我构建的速度快 7%)。正如 Zig’s New Relationship with LLVM 中所述,编译时间由 LLVM 主导,因此提高编译速度的唯一方法是 Zig 拥有自己的自定义后端。
公告指出,为最常见的架构构建自定义后端的工作已经开始,感兴趣的可以关注 0.10.0 发行说明中的进度报告。但可以总结一下,即:arm64 的进度约为 40%,x86_64 的进度约为 60%。启用这些后端后,你的程序的调试构建将完全绕过 LLVM。
C 后端
开发团队还在开发一种特殊的后端,它可以生成 C 源代码。而得益于一个惊人的贡献,C 后端的进展最近突飞猛进(87% 并且还在增加) 。
“这个后端的有趣之处在于,它将在我们替换旧的 bootstrap compiler 实现的计划中发挥作用;也许更有趣的是,它将允许 Zig 以 LLVM 不支持的架构为目标, 包括那些迫使你使用特定 C 编译器的架构,如某些游戏机平台。”
编译器开发速度
作为语言的使用者,你不会直接体验到 bootstrap compiler 代码库与新代码库之间的差异,但这种变化也会影响到你,因为它将影响到花费在编译器上的总工作量。
目前 Zig 已经开始有更多的人对编译器做出贡献。“我自己就是一个例子:我已经开始致力于自动化文档系统的新实现”。现在对编译器的贡献已经变得更容易了。
新的 for 循环语法
一个例子是即将实现的新 for 循环语法,它也支持 ranges。不过值得注意的是,这不会包含在 0.10.0 版本中。
const nums = [3]usize {42, 42, 42}; const chars = [3]u8 {'a', 'b', 'c'}; // easy "zip" iteration (all arguments must have the same length) for (nums, chars) |n, c| { ... } // easy range loops for (0..3) |idx| { ... } // but this won't work anymore (old syntax) for (chars) |c, idx| { ... } // now you need a range if you want an index for (chars, 0..) |elem, idx| { ... }
为 multi-argument for loops 提供 language-level 支持:
- 允许进行 hoist out-of-bounds checks,提高安全构建模式(Debug、ReleaseSafe)下的性能。
- 鼓励与 MultiArrayList 和其他面向数据的设计技术一起使用的内存访问模式。
- 提供简洁的语法来进行 ranges 循环。
阅读有关此语言提案的更多信息。
官方包管理器
一旦自托管编译器与 bootstrap 编译器达到功能对等,开发团队将开始处理官方包管理器的第一次迭代。“我们并不期望首先尝试确定每个设计方面,但我们确实知道我们想要朝着哪个大方向前进”。
第一次迭代的主要目标是启用依赖项的简单使用来开始构建包生态系统,并确保可以轻松打包 C/C++ 项目,而不仅仅是 Zig。Zig 构建系统已经可以构建 C/C++ 项目,“因此我们希望确保我们可以利用 40 多年的开源工作,而不仅仅是 Zig 重写。也就是说,支持 C/C++ 不仅有利于 Zig,因为我们相信 Zig 可以帮助简化仅打算将 Zig 用作编译器和构建系统的项目的获取和构建依赖项的过程。”
有关官方包管理器的特定功能,目前的看法为:
- 包管理器将成为编译器的一部分,而不是单独的可执行文件。Zig 是一种语言和编译器工具链。
- 包管理器不会假定存在中央包索引。不打算创建官方包索引。
- 版本解析将类似于 Go 的最小版本选择,但有一个额外的限制:stable packages 将只能依赖于其他 stable packages(例如,一个
v1.x
包不能依赖于一个v0.y
包)。
“我们对这些决定相当有信心,除了稳定性限制。好消息是,如果它被证明过于苛刻,我们总是可以在不破坏现有包的情况下放松这一限制。”
更多详情可查看官方博客。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Linus 认为是时候从内核移除对 i486 CPU 的支持
近日,Linus Torvalds 在邮件列表回应了对从内核移除英特尔 i486 处理器支持的想法。 Linux 内核十年前移除对 i386 的支持后,i486 一直是内核主线对 x86 架构支持的最低版本。Linus 说道:“我们早在 2012 年就取消了对 i386 支持,也许 2022 年是时候取消支持 i486 了?” Linus 认为大家应该“咬紧牙关”,让 x86 架构 32 位 CPU 的最低支持版本提高到"cmpxchg8b",即奔腾及更高版本。他表示,大多数(甚至是所有)发行版已经启用了 X86_PAE,这使得 X86_CMPXCHG64 成为基本要求的一部分。 事实上,早在一年前就已经开始讨论从内核移除i486 支持。当时有一名开发者表示自己还在使用 i486 系统,并声称仍然有一些实际用途。但整体来看,在 i486 上运行现代发行版/内核的 Linux 用户极其罕见。所以 Linus 坚持要从内核放弃 i486 支持的想法。他认为 i486 硬件已经没有什么意义,虽然这些硬件仍然存在,但从内核开发的角度来看,这些工作没什么价值。 Linus 指出,既然 i486 ...
- 下一篇
SUSE Edge 2.0 亮相 KubeCon,全面优化边缘管理
SUSE Edge 2.0 全面整合了旗下 Linux 和 Kubernetes 管理解决方案,旨在为用户提供一个可扩展边缘运行的安全堆栈 同时在北美 KubeCon 大会上亮相的还有 SUSE Rancher 的多项创新成果,旨在强化云原生工作负载安全 KubeCon 北美大会,底特律 - 2022 年 10 月 25 日 - 全球范围内创新且可靠的企业级开源解决方案领导者SUSE 发布了多项技术创新,旨在助力客户简化部署和扩展边缘基础设施,从而推进边缘运营转型。SUSE Edge 解决方案 将 Rancher、SUSE Linux Enterprise (SLE) Micro 和 SUSE NeuVector 的多项创新功能集于一身,汇聚成为一个高度安全、集成化的可扩展平台,能够通过分布式边缘环境实现对 Kubernetes 和 Linux 操作系统生命周期的简化、集中化和自动化管理。 “通过将广受业内认可的轻量级 Kubernetes 发行版与专为边缘环境打造、具备企业级安全保障的 Linux 操作系统相结合,我们成为了云原生解决方案的先驱者之一,能够帮助客户应对扩展中的诸多挑...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2配置默认Tomcat设置,开启更多高级功能