OSC 协作翻译 编译自：Rust vs. C : Fine-grained Performance 链接：http://cantrip.org/rust-vs-c .html 译者：Viyi,Tocy,边城,snake_007,xufuji456 如果 Rust 要做 C 做的工作，我们需要知道 Rust 会把 C 最擅长的工作做成什么样子。什么是快，什么是慢？ 什么更难做，什么更容易？ 我不知道该如何回答这些问题，但我可以编写程序来寻求答案。 我有一个 C 程序，其长度用来实验正好合适一个打印的页面长度，并且使用不熟悉的语言重写也不会有什么棘手的问题。（它生成由 Frank Longo 设计的名字为“拼写蜜蜂”的拼图游戏的所有可能的方案，我是在“纽约时报”杂志发现的。）我在 Rust 上使用等效的代码直接重写了该程序。Rust 程序的长度与之前 C 的接近，但运行效率只有原来的一半。因为我使用了更加规范的 Rust 代码管理，它运行得更快。同时，我努力加快 C 程序执行速度，仍然保持原来的代码长度一页**。每次更改后，我都会检查下性能。很少有程序得到这么多的优化关注。 C 版本现在运行的速度是我开始时的三倍；我认为在不改变增加其长度、不考虑并行或者不使用第三方库的情况下，这基本达到在性能最佳的要求。在现代硬件上 90ms 内，它执行大约 1.9 亿次基本操作（每次迭代的 1 个时钟周期），过滤高达 500 万次更复杂的操作（每位占用 28 个时钟周期）。同时，Rust 程序大致在相同的时间执行相同的操作：在不同硬件上只有几个百分比的更快或更慢差距。许多变量显示似乎他们应该运行速度相同或更快但结果却是速度更慢，通常是慢得多。相比之下，在C 中很难发现表达相同操作的不同方式，并获得不同的运行时间。 来看程序。首先是依赖项：头文件，模块。 C : 和 Rust: 这里 Rust 赢了。Rust 提供大量默认的标准库。上面的代码中，就第一行，就 use 了一堆模块。Rust 的模块系统非常典型；任何未来的语言都不能忽视这种模块系统。 然后是参数和处理输入文件。 C : 和 Rust： 在这一点上 C 获胜。用 Rust 来做这些事情需要更多代码。多数使用 Rust 的人都会让这种简单的程序，因为“恐慌”而报告用法错误，虽然这样产生的输出非常难看。使用 Rust 很难放过一个 I/O 错误，只要这不会让人们习惯忽视之些错误，就不算坏事；在 Rust 中忽略错误需要很多工作。 两个程序都从命令行获得一个可选的文件名参数，并从 stdin 读取数据，用于测试转换。在标准的 Linux 系统中，words 文件保存着真实的英文单词列表，包含合适的名称、缩写和需要过滤掉的短小单词。注意这里使用 Box 擦除类型，因此可以使用 io::stdin 来代替 fs:File 句柄。奇特的 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
