※ 引述《os653 ()》之铭言：
: 最近在练习 Rust，听说执行速度可以跟 C 相当
: 但看了下面网页的执行速度比较，似乎 Rust 还是略输一截
: https://benchmarksgame.alioth.debian.org/u64q/rust.html
: 请问这是为什么？
: 在我的粗略理解上，Rust 的很多东西都是在编译期就处理掉了
: 而且因为变量的定义较为严格，还有可能编出较短的机械码
: 那理论上应该会比 C 快才对呀？
Hi, 在开始说明前，建议你可以先看一下 benchmarks game 针对效能比较的说明
https://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html
他们开宗明义就讲：每个程式语言设计时要达成的目标不一样
单纯地实作相同算法并比较它们的效能，其实是LP比鸡腿
Rust 在设计上的首要目标是 memory safe 与 thread safe
并且在提供高阶抽象化的同时，尽可能维持良好的执行效能
而 C 的目标是取代当时 (1973) 虽然效能好但不易跨平台的组合语言
因此它允许 undefined behavior，而且提供许多低阶的操作
确实 Rust 在 compile time 就做了许多 safety check 来提高 runtime 效率
但有些与 memory safety 相关的检查确实很难在 compile time 实现
而 C compiler 根本就不管 memory safety 的
这种时候，Rust 的执行效率确实会比 C 还要慢
最简单最常见的例子就是阵列存取
像这样的程式码：
array[i] = x;
Rust 的效率会明显低于 C
因为 compiler 无法在 compile time 确认 i 是否落在 array 的长度限制内
为了不引发 undefined behavior，它必需在 runtime 帮你做边界检查。
事实上，所有 memory safe 的语言，在这样的阵列存取时都会做边界检查。
大家会说 Rust 的效能很好，多半是与其它 memory safe 的语言比较
比如说 C# / Java / Go，而不是和 C 比较。
* * *
所以 Rust 一定比 C 还要慢吗？那也不一定。
你可以看看 C 与 C++ 在 benchmarks game 上面的比较，
几乎所有的测试中 C 都比 C++ 还要快。
但是，如果你比较 C++ 的 std::sort 与 C 的 qsort
那么 C++ 肯定是压倒性的胜利
当然，如果要比排序，你还是可以用 C 手刻一个与 C++ sort 相同的版本
但，当你使用某个语言写程式，而标准函式库提供了 qsort
你还会手刻一个自己的 sort 出来吗？
“使用某语言”在一定程度上，包含了“使用某语言的library”
这也算是 benchmarks game 的一项规则
上面的测试程式码会尽可能使用该语言提供的函式库
以符合使用该语言写程式的普遍情况
因此，benchmarks game 上面某个语言的效能，应该要被理解为它的“平均表现”
而不是该语言的“极限”
以 C 与 Rust 的比较中，其中 C 表现得比较好的测试像是 mandelbrot 或 n-body
C 都使用了 SIMD 指令以提升效率
但是目前 Rust 的 SIMD 尚未成为标准功能，因此范例码中也未使用 SIMD 加速
这是否表示 Rust 不能用 SIMD 呢？并不是
你真的想做，还是可以用 unsafe block 与 inline asm 做到
但这不会是 Rust programming 的常态
毕竟如果你那么在意效能，觉得效能比 memory safe 或易读易写更重要
那 C 还是比较适合的选择

C 的 qsort 比 C++ 的 std::sort 慢是差在 template?

可能是; C++ 有 template 所以可以 inline 比较函式但 qsort 一定是(间接)呼叫我没实测过所以这只是推测就是了

std::sort不是单纯quick sort

quick sort到一半改用heap sort 这是现在最快的纯比较排序法

std:sort 用的是 intro sort

以前都苦干几个以下用哪种,几个以上用哪种,多少要拆.

SGI STL 的 std::sort 不是 quick sort

喔对, 忘了它是 intro sort...

感谢说明，其实我也很好奇为啥在C的部分会看到omp的东西想说比速度不是应该用同条件去比才对吗？照您的说法就说得通了

不同的lib的std::sort 实作都不太一样，clang的好像是5pivot的quick sort