wordpress网站转app,欧盟理事会,十大软件排行榜,商标查询官方入口Nethercote是一位研究Rust编译器的软件工程师。最近#xff0c;他正在探索如何提升Rust编译器的性能#xff0c;在他的博客文章中介绍了Rust编译器是如何将代码分割成代码生成单元#xff08;CGU#xff09;的以及rustc的性能加速。
他解释了不同数量和大小的CGU之间的权衡…Nethercote是一位研究Rust编译器的软件工程师。最近他正在探索如何提升Rust编译器的性能在他的博客文章中介绍了Rust编译器是如何将代码分割成代码生成单元CGU的以及rustc的性能加速。
他解释了不同数量和大小的CGU之间的权衡以及Rustc是如何使用LLVM并行化代码生成和优化的。此外Nethercote还探索了一些形成和排序CGU的替代方法并报告了他的实验结果。
Nethercote发现很多时候无法在编译速度、内存占用、编译体积和质量上都实现提升一个指标的提升经常伴随另一个性能指标的下降。尽管他没有发现比现有方法更明显的改进但还是希望在未来继续研究这个问题。
如何提升Rust编译器速度这篇文章或许能帮助到你
1、LLVMRust编译加速的秘诀
Rust的MIR是HIR到LLVM IR的中间产物将MIR转换为LLVM IR然后将其传递给LLVM从而生成机器代码。在此过程中LLVM能通过处理多个模块实现并行。Rustc使用LLVM加速Rust的编译。我们称其中的每个模块为“代码生成单元CGU”。 图时间位于 x 轴上每条水平线代表一个线程。主线程显示在顶部标有 PID。它在开始时处于活动状态时间足以产生另一个标记为 的线程rustc。rustc底部显示的线程在大部分执行过程中都处于活动状态。还有 16 个 LLVM 线程标记opt cgu.00为 到opt cgu.15每个线程都会在短时间内处于活动状态。
CGU实际上是如何形成的呢粗略地说Rust 程序由许多函数组成这些函数形成一个有向图其中从一个函数到另一个函数的调用构成了一条边。我们需要将这个图分割成块CGU这是一个图分区问题。我们希望创建大小大致相等的 CGU因此 LLVM 处理它们所需的时间长度大致相同并最大限度地减少它们之间的边数因为这使 LLVM 的工作更轻松并带来更好的代码质量 。
实际上由于我们上面看到的阶梯效应我们不希望 CGU 的大小完全相同。理想的情况是 CGU 大小存在与梯度相匹配的轻微梯度。这样所有 CGU 将完全相同地完成处理以实现最大程度的并行化。 合并之前的CGU9个
Nethercote认为在合并之前“调整”CGU可能会有所帮助在某些情况下将函数从一个CGU移动到另一个。例如如果在CGU A中被调用f的叶函数即不调用任何其他函数的叶函数在CGU B中有一个调用方g那么将f从A移动到B是有意义的从而去除CGU间的边。还有其他类似的情况涉及非叶函数移动也有意义。我实现了这一点它给出了一些适度的改进但我目前还没有决定它是否值得额外的复杂性。 调整之后的CGU5个
在实现这一点的同时我还花了一些时间来可视化调用图。我从GraphViz开始。这些图表对于非常小的程序来说看起来不错但对于较大的程序来说它们很快就变得无法读取和导航。我在Mastodon上抱怨过这一点并得到了使用d2的建议d2速度较慢但图形可读性更强。 2、后端并行方法的软肋
图划分是一个 NP 难题。有几种常见的算法实现起来相当复杂。相反rustc 做了一些更简单的事情。首先简单地为每个 Rust 模块创建一个 CGU模块中的每个函数都放入同一个 CGU 中。然后如果 CGU 数量超过限制默认情况下非增量构建为 16 个增量构建为 256 个它会重复合并两个最小的 CGU直到达到限制。这种方法简单、快速并以有用的方式利用特定领域的知识——程序模块往往提供良好的自然边界。
所有这一切都依赖于测量 CGU 大小的方法。目前使用CGU中的MIR语句的数量来估计LLVM处理CGU需要多长时间。这里有很大的设计空间有许多其他可能的形成和规划CGU 的方法。 这种转换对Rust众多语法糖进行了脱糖并且极大精简了Rust的语法但并非其语法子集是观察和分析Rust代码的常用手段尤其是在控制流图和借用检查等方面。
在这篇文章的最后Nethercote提供了几个数据集的链接每个数据集都记录了编译rust -performance基准时每个CGU的测量值。这些数据集包括许多测量静态代码大小的输入独立变量例如函数数量和MIR数量等。
Nethercote试着用scikit-learn做一些基本的分析。并且通过这些基本的分析能让Nethercote仔细推敲到底应该搜集哪些测量值。
通过一系列的改进优化他获得的最终数据集比刚开始时的数据更准确。但是并没有通过这些数据获得多少实际的结果。实际上每次我对测量的内容改变后都会得到完全不同的结果。
3、实现更快的Lexer
词法分析lexical analysis是编译器的第一个阶段实现词法分析的代码称为lexer。
有人最近研究了logoshttps://github.com/maciejhirsz/logos这个在rust中广受欢迎的lexer。
此前logos声称其目标是能比手动实现的lexer更快作者提出了质疑因为在他看来通用性和性能无法兼得。因此他一步步实现了lexer探索了多种优化技巧并与logos进行了多轮性能对比。
最终的结果表明手动实现的基于状态机的lexer比logos实现了20%左右的性能提升。
4、从错误中学习使用Rust实现DLL注入
Rust是一种注重安全性的编程语言但在某些情况下开发人员可能需要使用unsafe关键字来执行某些操作。unsafe可以提供更高的性能但可能会牺牲安全性。因此开发人员在使用时需要非常小心。几个使用unsafe的常见场景包括访问裸指针、调用外部C函数等并提供了一些建议和最佳实践以确保在使用unsafe时不会引入潜在的安全隐患。
举个应用方面的例子原来作者一直在用C编写逆向工具但是C这门语言并不友好于是研究了下如何使用Rust实现DLL注入的“工具”。
大致原理就是让Rust首先生成一个C样式的DLL然后使用unsafe操作裸指针操作程序内存最后实现DLL注入就可以了。
5、期待更准确的估计函数
Nethercote 希望具有数据分析专业知识的人可以做得更好重点关注以下几个方面
1更匹配的估计函数
2想要使编译器比现在更快一个更好的估计函数也许不会达到预期的效果。我提出了一些更好的统计方法但并没有提升编译速度甚至变差。
3CGU调度效果不可预测你不能假设一个估计函数好几个百分点就会使编译器更快。话虽如此我希望改进力度足够大能够转化为实际的加速。
4对于估计函数来说最好高估CGU编译所需的时间而不是低估。
5我很担心过度拟合。数据集来自一台机器但实际上rustc会运行在不同的机器上具有各种各样的体系结构和微体系结构。
6这些数据集来自单一版本的rustc使用单一版本的LLVM。我担心随着时间的推移准确性可能会漂移。
7我更喜欢不太复杂且易于理解的估计函数。当前的函数非常简单在大多数情况下只是增加了基本模块和语句的数量。例如0大小的CGU应该别估计为花费非常接近于0的时间。
8估计函数有一个明确的问题即如果不考虑其内部公式计算MIR语句可能非常不准确。特别是单个MIR语句可能变得很长。举个例子深度向量压力测试的MIR包含一条语句该语句定义了包含超过100000个元素的向量字面量。不出所料当前的估计函数严重低估了编译这个基准所需的时间。
Nethercote最后提醒希望以上的请求是合理的
以下是上文提到的数据集
调试构建主要基准测试
https://nnethercote.github.io/aux/2023/07/25/Debug-Primary.txt
选择构建主要基准
https://nnethercote.github.io/aux/2023/07/25/Opt-Primary.txt
调试构建二级基准测试
https://nnethercote.github.io/aux/2023/07/25/Debug-Secondary.txt
选择构建二级基准
https://nnethercote.github.io/aux/2023/07/25/Opt-Secondary.txt
顺便说一句在这些数据集中主要基准测试比次要基准测试更重要次要基准测试包括压力测试、微基准测试和其它不符合实际的代码。 相关内容拓展技术前沿
近10年间甚至连传统企业都开始大面积数字化时我们发现开发内部工具的过程中大量的页面、场景、组件等在不断重复这种重复造轮子的工作浪费工程师的大量时间。
针对这类问题低代码把某些重复出现的场景、流程具象化成一个个组件、api、数据库接口避免了重复造轮子。极大的提高了程序员的生产效率。
推荐一款程序员都应该知道的软件JNPF快速开发平台采用业内领先的SpringBoot微服务架构、支持SpringCloud模式完善了平台的扩增基础满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力采用前后端分离模式前端和后端的开发人员可分工合作负责不同板块省事又便捷。
体验官网https://www.jnpfsoft.com/?csdn还没有了解低代码这项技术可以赶紧体验学习 参考资料 1.https://nnethercote.github.io/2023/07/25/how-to-speed-up-the-rust-compiler-data-analysis-assistance-requested.html 2.https://geo-ant.github.io/blog/2023/unsafe-rust-exploration/ 3.https://nnethercote.github.io/2023/07/11/back-end-parallelism-in-the-rust-compiler.html
