※ 引述《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 還是比較適合的選擇