Re: [問題] 請問關於 Rust 跟 C 的速度比較

看板C_and_CPP作者littleshan (我正在想要換什麼)時間8年前 (2017/08/13 17:32)推噓6(6推 0噓 10→)

留言16則, 9人參與討論串2/2 (看更多)

※ 引述《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 還是比較適合的選擇 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.227.5.133 ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1502645537.A.264.html

推

FRAXIS

08/14 06:05, , 1^F

08/14 06:05, 1^F

推

LPH66

08/14 07:49, , 2^F

08/14 07:49, 2^F

→

LPH66

08/14 07:49, , 3^F

08/14 07:49, 3^F