作者os653 ()
看板C_and_CPP
标题[问题] 请问关於 Rust 跟 C 的速度比较
时间Sat Aug 12 21:49:05 2017
最近在练习 Rust，听说执行速度可以跟 C 相当
但看了下面网页的执行速度比较，似乎 Rust 还是略输一截
https://benchmarksgame.alioth.debian.org/u64q/rust.html
请问这是为什麽？
在我的粗略理解上，Rust 的很多东西都是在编译期就处理掉了
而且因为变数的定义较为严格，还有可能编出较短的机械码
那理论上应该会比 C 快才对呀？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.41.63.59
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1502545749.A.9F5.html
1F：→ loveflames: 你的理论依据没有一个可以当成比C快的理由 08/12 22:08
2F：→ loveflames: 应该反过来问，为何你会觉得这些会是速度比较快的原因 08/12 22:09
3F：推 CoNsTaR: 虽然 rust 可以利用规则来简化复杂的东西 08/13 06:11
4F：→ CoNsTaR: 但是相反的，因为 rust 只能照规则走 08/13 06:11
5F：→ CoNsTaR: 所以不在规则内的 hack 就没办法过 type check 08/13 06:11
6F：→ os653: 版上的教学网页有提到 08/13 09:49
7F：→ os653: void foo(int* x, int* y, const int* z) 08/13 09:50
8F：→ os653: { 08/13 09:50
9F：→ os653: *x += *z; 08/13 09:50
10F：→ os653: *y += *z; 08/13 09:50
11F：→ os653: } 08/13 09:50
12F：→ os653: 这样一个函数，因为C的编译器无法确定x、y、z是否是同一块 08/13 09:51
13F：→ os653: 记忆体位址，而Rust的编译器可以确定，故C编出来的机械码会 08/13 09:53
14F：→ os653: 比Rust多一次读取的动作，就会比较慢一点 08/13 09:54
15F：推 CoNsTaR: 就说 rust 会在他知道的范围内把东西做到最简 08/13 11:10
16F：→ CoNsTaR: 所以如果 rust 知道所有最快的 hack 08/13 11:10
17F：→ CoNsTaR: 而且能够知道同一个语意的所有不同写法 08/13 11:10
18F：→ CoNsTaR: 那理论上它会是最快的，但事实是不可能，只能尽力 08/13 11:10
19F：推 CoNsTaR: 例如说，如果有一种机器，它有一个指令能够在一个指令周 08/13 11:15
20F：→ CoNsTaR: 期内做完 foo 做的事，但是 rust 不知道这个指令，或者是 08/13 11:15
21F：→ CoNsTaR: rust 不知道直接呼叫那个指令和执行这一串程式码是相等 08/13 11:15
22F：→ CoNsTaR: 的(操作语意上)，那这两个情况下 C 内嵌组语都会比 rust 08/13 11:15
23F：→ CoNsTaR: 快 08/13 11:15
24F：推 CoNsTaR: 而各个 libc 的实作都用了一大堆这种机器相关的 hack， 08/13 11:17
25F：→ CoNsTaR: 所以 rust 才会这麽难超过 C 08/13 11:17
26F：推 CoNsTaR: 至於为什麽我前面说不可能，第一因为这种 hack 可以有无 08/13 11:21
27F：→ CoNsTaR: 限种，你随时爽往你的机器上加什麽特性都可以 08/13 11:21
28F：→ CoNsTaR: 第二因为对於所有正确的叙述，要判断它们的语意是否相等 08/13 11:21
29F：→ CoNsTaR: ，常常是 undecidable 的 (有兴趣可以参考 logical seman 08/13 11:21
30F：→ CoNsTaR: tics) 08/13 11:21
31F：推 CoNsTaR: 所以如果你不知道两者语意相等，那你就没办法用快的取代 08/13 11:29
32F：→ CoNsTaR: 慢的 08/13 11:29
33F：→ CoNsTaR: 例如你上面的例子，如果 rust 不能判定少读一次记忆体位 08/13 11:29
34F：→ CoNsTaR: 址的语意是否还和原本一样，那它就没办法用少读一次的版 08/13 11:29
35F：→ CoNsTaR: 本替换比较慢的版本(虽然这个 case 是可判定的) 08/13 11:29
36F：推 CoNsTaR: 不知道这样讲有没有比较清楚… 08/13 11:33
37F：→ grayStone: 我对楼上的解读是，没错Rust比较快 08/13 12:48
38F：→ PkmX: compiler和library实做完全不一样啊... 08/13 15:24
39F：→ os653: 我想C大的例子就类似用DMA跟以byte为单位读取资料的差别吧 08/13 18:37
40F：→ os653: 一个用一行指令就完事，一个要用for回圈跑几千次这样 08/13 18:38
41F：→ os653: Rust平常小胜，遇到可以取巧的指令大输，结果就变成小输 08/13 18:42
42F：推 james732: Rust在实作上没有取巧的空间吗？ 08/13 18:49
43F：推 Hazukashiine: @os653 可以用 restrict 提示 C Compiler 那两个 08/13 20:42
44F：→ Hazukashiine: pointer 不会 alias 因此没有你说的那个问题不存在 08/13 20:43
45F：推 Hazukashiine: -s 删--xx-- 08/13 20:45
46F：推 LPH66: 不过 restrict 只有 C99 有, C++ 因为多型的关系状况复杂 08/14 01:48
47F：→ LPH66: restrict 的语意碰上多型会有麻烦所以目前一直都没有规定 08/14 01:48
48F：→ LPH66: (连 restrict 在 C++ 都不是关键字) 08/14 01:49
49F：→ LPH66: 虽然 g++ 有提供 __restrict 给 C++ 用但我不太清楚语意 08/14 01:50
50F：→ LPH66: 修正一下, 是 C99 以後的 C 才有 08/14 01:52
51F：推 ronin728: 那个网站写测试程式的人都尽量压榨效能，你可以点code 09/18 08:09
52F：→ ronin728: 来看看，C语言的code有强大的GMP护驾 XDD 09/18 08:09
53F：→ ronin728: GMP 好歹也是社区经营多年，测试结果数一数二的数学库 09/18 08:10
54F：→ ronin728: 不过有好几个测资确实无关lib，是rust比较慢 09/18 08:12