Re: [討論] Python 3.10將加入Switch-Case語句

[Muscovy (三分熟的鬧鐘)]

※ 引述《Muscovy (三分熟的鬧鐘)》之銘言：

        一回神竟然引發這些有趣的討論.
        來稍微介紹一下我的工作背景: 我是在上市公司做高效能運算的單位主管.
        算什麼無聊東西就不要問了, 不過特別強調, 不是博弈或者加密貨幣. :D

        我的一個 block 通常會吃掉 100%~500% CPU, 生命期介於 2~48 hours.
        執行階段佔用記憶體大概是 20GB~30GB 之間, 偶爾會用到 memory map.
        再長的話不敢做, 會分段跑, 因為 windows 會當. XD
        （MacOS 穩定一百倍, 但是公司不配發, 所以... ）

        因此, 我想我比絕大部分的人更在意「運算效能的問題」.

        在我的例子裡面, 每個迴圈執行的時間不會低於三十分鐘.
        所以這些 iteration 本身的 overhead 不是問題, 因為都是毫秒級.
        但是如果你關心效能的話, 拆出一堆 for-loop 才是正確的寫法.
        因為這種寫法「對於效能」最大的好處是平行化.

        怎麼平行化? 幾個 for-loop 就拆幾隻程式跑啊, 簡單得很.

        接下來講的就比較難一點.
        加速最重要的其實是 cache utilization.
        其次是 pipeline utilization.
        這種 instruction level optimization, 很重要.
        我給各位一個大概的概念...
        cache utilization 做得最好與最差, 執行效率大約 x50~x100 倍.
        pipeline utilization 的話, 幾層 pipeline 就是幾倍.
        反觀你的 CPU 辛辛苦苦買到 12 核心, 全佔滿大約加速 4~5 倍.
        把 12 核通通算到過熱它還會降頻跑, 又更慢了, 你看多廢.

        然後 instruction level optimization 的部分.
        教科書一開始就會說:
        1.) data layout & access pattern 很重要.
        2.) 迴圈裡面不要放 branch.
        因為 principle 1.) 顧 cache, principle 2.) 顧 pipeline.

        當然 python 本身很難做到這件事.
        不過你可以去找 hardware accelerated library.
        最知名的就是 tensorflow + GPGPU.
        tensorflow 這咚咚不只能做 AI, 它也是高效能的線代運算核心.
        一樣, 為了顧效能, 你也會把自己搞成這種寫法. XD

: --
: 推 neo5277: 好像是滿好玩的 關心值 不知道會不會比較有效果
: → Murasaki0110: 變成5次for好在哪裡
: → alihue: 第二種其實 eig 會被 scan 五次？效能不是比較差嗎

        不只會 scan, 實務上甚至有可能花 10 秒重建一個超大矩陣.
        但是多這 10 秒, 反而可以讓你提前幾十分鐘結束運算.

: 推 drajan: “pythonic”

        "pythonian," 來戰! 哈哈哈.

: 推 noahleft: 第二種以維護角度比較容易, 第一種當條件混入各種可能後
: → noahleft: 會很難知道甚麼時候會跑到哪個條件
: → noahleft: 只要考慮到有情形是多個條件都能成立時,第一種寫法就是
: → noahleft: 看執行順序,而第二種寫法會變成餵進來的資料都是符合條
: → noahleft: 見的

        是的, 尤其是你看到一堆論文, 每篇都要實作才知道有沒有唬爛.
        你會發現不太可能用 for-loop 內嵌一堆 if-else 去做這件事.
        因為本質上你是在重建數學家的工作, 你的程式碼要越接近數學形式越好.

        然後做久了會發現, 一行數學式對一個 for-loop 最直觀. XD

: → hsnuyi: 又是一個不考慮CPU如何branch的人
: → WunoW: NO 你先if排除不符合的條件更直觀也有更好的效能
: → WunoW: 我知道你是想遵循單一職責原則，但這不是定律
: → WunoW: 一個迴圈做多個判斷沒有不行 你判斷式提取為函式就好
: 推 alihue: 樓上說到一個重點...if的位置在某些情況可以大幅改善效能
: → WunoW: 你去看pandas的源碼吧 一個for loop裡面包山包海的code一堆
: → alihue: 例如在迴圈的一開始就篩掉大部分 case 並 continue
: 推 MoonCode: 先寫的簡單好懂比效能重要 推推
: 推 jack0204: 樓上說的這叫early return，寫可讀性高的程式常用到

        我上面講的都不是學術界裡的象牙塔, 僅供寫論文之類的.
        是道道地地發生在產業中的每日工作.
        跟我的運算類似的產業叫做 ADAS, 他們也在寫類似的寫法.
        光是一邊能無腦拆, 另一邊因為內嵌 if 不能無腦拆...
        不能拆的那邊就準備被一堆 AWS 做翻.

        或者俗氣一點, 畢竟是 soft JOB.
        如果年紀輕輕就已經知道上面那些小訣竅, 面試進聯發科的機率很高哦.
        夠俗氣吧, 但挺有用的.

        所以你知道的, 為了效能, 你更應該寫一堆 for-loop.
        這絕對不是異端學說. XD


--

  新詩練習：新鮮。踩破初春裡的狗大便；不經意的滄桑，滿溢著嫩黃的喜悅。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.47.50 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1616862026.A.F6D.html
推 yislin: 推解釋詳細
推 x9060000456: 推
→ yislin: 好奇請教一下，如果捨棄 for loop，改成將 subarray 傳遞
→ yislin: 至 function，而後再回傳，如此一來在優化上是否更好做？
→ yislin: 再多問些，如果再加上 map 呢
推 alihue: 如果你前提是每個 for-loop 拆出程式分開跑當然效能好
→ Muscovy: @yislin, 你給的條件對我來說比較像是維護性的問題.
→ alihue: ，但前篇文章前提是同支程式。
→ alihue: 此外並不是講職稱就能把你的話直接變成正解，技術要合理
→ alihue: 才能。
→ Muscovy: 維護性也蠻重要的, 一味優化的結構很恐怖, 隔天就看不懂.
→ alihue: 我並沒有要反駁說這篇哪個做法是錯的，因為
→ alihue: 這篇又多加了幾個前提，那解法又更不同。
→ Muscovy: @alihue, 其實我只是「從效能的觀點」來說... XD
→ alihue: 我自己也在每天幾千 QPS 的系統工作，但我不會認為我是正
→ alihue: 解
→ Muscovy: 從維護性來說, 我的經驗也告訴我, for + if 少用為妙.
→ Muscovy: 因為出錯的時候真的很難 debug, 尤其一群猴子合作的情況
→ Muscovy: 對, 我就是說我們的團隊... XD
→ paimin: 我們都直接買64 core的給大家跑 優化有空再做就好了
推 taipoo: 推
→ handsomeLin: 如果要拆來跑的話當然是拆開for loop跟preprocessing
→ handsomeLin: 的概念是一樣意思，但是這樣跟用不用if在for loop裡s
→ handsomeLin: cope就完全不同了
→ Murasaki0110: 沒平行的時候硬要這樣寫就是慢啊
→ Murasaki0110: 你前提是平行那也沒討論if的必要
噓 majohnsha: 台灣主管真敢講 說自己團隊是猴子
→ majohnsha: 真好奇哪家上市公司
→ recorriendo: 看起來你的loop順序不影響結果 那直接做data paralle
→ recorriendo: l 有幾個entry就拆成幾個job 不是更快？
推 j0958322080: 搞不好人家只是謙虛而已
→ Muscovy: 不是謙虛! 而是... 薪水用鄉民的眼光看, 真的是香蕉等級
→ Muscovy: data parallelism 是其中的部分考量而已.
→ Muscovy: 而且運算量大的時候, 常見的拆法也不能用.
→ Muscovy: 因為通常也會伴隨 bandwidth 的問題.
→ Muscovy: bandwith 「不足」... 漏寫.
→ Muscovy: bandwidth........一直打錯.
推 vi000246: 同意越接近數學越好維護
→ shooter555: 指令集的問題就變成要看指令集提供哪些運算了 看可以
→ shooter555: 一次運算幾個byte 再來拆loop 畢竟很多餘數特例
→ shooter555: 不過講到這個就要完全捨棄可維護性了 在加速部份
→ shooter555: 每個迴圈運行的時間不低於三十分鐘 那的確可以捨棄掉
→ shooter555: 展開的時間了
→ shooter555: 但如果這個function是不到一毫秒執行一次可能會有差
→ shooter555: 平行化也不是這麼好用 畢竟還要考慮到race condition
→ shooter555: 三十分鐘這麼長的確可以拆幾個thread來跑 但必須確保
→ shooter555: 些來的資源不共用 或要另外lock
推 ShenJing: 推解釋，有所收穫
→ loggan: 有問有人知道內文提到的教科書是？
推 s0914714: 如果那麼在意效能應該是不要用(原生的)Python
推 kqalea: 我認同，看看VPP DPDK
→ kqalea: 我更覺得 LLVM Backend 是更好更理想的解法