Re: [討論] 寫三元判斷式code review被打槍

[EricTCartman (阿ㄆㄧㄚˇ)]

※ 引述《unixxxx (皓皓)》之銘言：
: 隨著語法的進步
: 很多會寫 code 的人都很少寫判斷式了
: 很多Javascript 高手都是用 switch 取代

好啦 假設不是反串 我覺得滿有道理的

但有一點其實你說錯了 其實並不是語法進步

之前學 Rust

覺得哇 pattern matching 真是他媽神 好潮喔

後來跑去學 OCaml 我才發現(Rust設計者是OCaml粉 一開始的compiler就是用OCaml寫)

阿幹 原來很多觀念 OCaml早就有了

編譯器/直譯器還會幫你檢查你的match是不是包含了所有的case

老實講寫ML真的會帶來很多跟C/C++不同的思維


所以與其說語法在進步 不如說在語法在逐漸把過去FP的東西搬進來

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.111.242 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1671368370.A.6EA.html
※ 編輯: EricTCartman (36.231.111.242 臺灣), 12/18/2022 21:01:41
→ qss05: 是說switch的效率到底有沒有比if else高啊？之前看人家測
→ qss05: 試，超過3個選項的話，switch的效率比較好，但是之前跟別
→ qss05: 人討論，他一直堅持if效率更好，不管幾個判斷
現在編譯器很發達，如果雙方僵持不下，我是建議直接看asm跟量效能

阿如果看不懂asm，代表程度還沒有到要吵這種效能的地步

我的經驗是branch misprediction的效能影響還比較嚴重 而且實務上也更容易遇到

現在編譯器已經發達到有些人寫C++都不用reference跟pointer

O2 O3開下去速度照樣ㄅㄧㄤˋㄅㄧㄤˋ叫的地步

→ Apache: 看你編譯跟執行環境
※ 編輯: EricTCartman (36.231.111.242 臺灣), 12/19/2022 00:42:13
推 labbat: 看asm也不夠準啦，寫的程式碼片段讓分支預測器或快取預抓
→ labbat: 太好猜，那就會有虛假的跑分效應
→ Hsins: 辣個效能是能影響多少？有時間擔心 switch 跟 if else 的效
→ Hsins: 能差異，不如想想一些多層的 for 迴圈是不是必要…
推 kurtsgm: 普遍討論是多condition的情況下switch稍稍略優於if-else
→ kurtsgm: 但差異也很微小 與其在那邊爭哪個performance好 乖乖看情
→ kurtsgm: 境寫可讀性高的code還比較實際一點
→ antpro: 全部都放進 embedded system 跑來看看。
→ testPtt: switch有些語言改的很棒 結合lambda清爽很多
推 CoNsTaR: 不用吵了，array lookup 比 switch case / if else 都快
→ shooter555: switch 跟 if-else的速度在實際上真的有人在意嗎
→ leolarrel: 寫MCU的人比較會在意吧.老闆要最便宜的MCU但是搞最多的
→ leolarrel: 功能的時候...
推 tw11509: 我是聽朋友說在產線上每次都差一點點時間，累積起來就是
→ tw11509: 很多時間，當然有差
推 j0958322080: 寫韌體的會在意阿
→ jobintan: 條件少就用if else，條件多的話就switch囉。
→ jobintan: BTW，條件多的話，我還沒見識過三元判斷式的操作法。www
→ peter98: 在那邊扯switch跟if-else效率的  肯定是計算機架構沒學好
→ peter98: 系統的bottleneck很少出現在if/switch這種判斷式。。。
這篇有誰提到bottleneck的嗎 板上有人不知道80:20的嗎www

他的問題是if跟switch到底哪個效率好

以前也有人驗證過for迴圈寫成i++跟++i的差別 (結論是編譯器都會優化好)

當然就問題本身討論咩

※ 編輯: EricTCartman (36.231.110.182 臺灣), 12/24/2022 18:35:57
推 CoNsTaR: ++i 和 i++ 編譯器不一定會優化成一樣喔
→ CoNsTaR: 如果 i 是可以放進 cpu cache 的 type，i++ 因為回傳 ref
→ CoNsTaR:  所以不能 cache，會比 ++i 慢（慢很多）