作者Muscovy (三分熟的鬧鐘)
看板Soft_Job
標題Re: [討論] Python 3.10將加入Switch-Case語句
時間Sun Mar 28 00:20:24 2021
※ 引述《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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1616862026.A.F6D.html
1F：推 yislin: 推解釋詳細 03/28 00:31
2F：推 x9060000456: 推 03/28 00:32
3F：→ yislin: 好奇請教一下，如果捨棄 for loop，改成將 subarray 傳遞 03/28 00:37
4F：→ yislin: 至 function，而後再回傳，如此一來在優化上是否更好做？ 03/28 00:37
5F：→ yislin: 再多問些，如果再加上 map 呢 03/28 00:40
6F：推 alihue: 如果你前提是每個 for-loop 拆出程式分開跑當然效能好 03/28 00:42
7F：→ Muscovy: @yislin, 你給的條件對我來說比較像是維護性的問題. 03/28 00:43
8F：→ alihue: ，但前篇文章前提是同支程式。 03/28 00:43
9F：→ alihue: 此外並不是講職稱就能把你的話直接變成正解，技術要合理 03/28 00:43
10F：→ alihue: 才能。 03/28 00:43
11F：→ Muscovy: 維護性也蠻重要的, 一味優化的結構很恐怖, 隔天就看不懂. 03/28 00:43
12F：→ alihue: 我並沒有要反駁說這篇哪個做法是錯的，因為 03/28 00:43
13F：→ alihue: 這篇又多加了幾個前提，那解法又更不同。 03/28 00:44
14F：→ Muscovy: @alihue, 其實我只是「從效能的觀點」來說... XD 03/28 00:44
15F：→ alihue: 我自己也在每天幾千 QPS 的系統工作，但我不會認為我是正 03/28 00:45
16F：→ alihue: 解 03/28 00:45
17F：→ Muscovy: 從維護性來說, 我的經驗也告訴我, for + if 少用為妙. 03/28 00:45
18F：→ Muscovy: 因為出錯的時候真的很難 debug, 尤其一群猴子合作的情況 03/28 00:46
19F：→ Muscovy: 對, 我就是說我們的團隊... XD 03/28 00:46
20F：→ paimin: 我們都直接買64 core的給大家跑 優化有空再做就好了 03/28 01:17
21F：推 taipoo: 推 03/28 01:39
22F：→ handsomeLin: 如果要拆來跑的話當然是拆開for loop跟preprocessing 03/28 10:53
23F：→ handsomeLin: 的概念是一樣意思，但是這樣跟用不用if在for loop裡s 03/28 10:53
24F：→ handsomeLin: cope就完全不同了 03/28 10:53
25F：→ Murasaki0110: 沒平行的時候硬要這樣寫就是慢啊 03/28 10:59
26F：→ Murasaki0110: 你前提是平行那也沒討論if的必要 03/28 11:01
27F：噓 majohnsha: 台灣主管真敢講 說自己團隊是猴子 03/28 12:27
28F：→ majohnsha: 真好奇哪家上市公司 03/28 12:28
29F：→ recorriendo: 看起來你的loop順序不影響結果 那直接做data paralle 03/28 13:33
30F：→ recorriendo: l 有幾個entry就拆成幾個job 不是更快？ 03/28 13:33
31F：推 j0958322080: 搞不好人家只是謙虛而已 03/28 18:13
32F：→ Muscovy: 不是謙虛! 而是... 薪水用鄉民的眼光看, 真的是香蕉等級 03/29 00:49
33F：→ Muscovy: data parallelism 是其中的部分考量而已. 03/29 00:52
34F：→ Muscovy: 而且運算量大的時候, 常見的拆法也不能用. 03/29 00:53
35F：→ Muscovy: 因為通常也會伴隨 bandwidth 的問題. 03/29 00:55
36F：→ Muscovy: bandwith 「不足」... 漏寫. 03/29 00:55
37F：→ Muscovy: bandwidth........一直打錯. 03/29 00:56
38F：推 vi000246: 同意越接近數學越好維護 03/29 11:54
39F：→ shooter555: 指令集的問題就變成要看指令集提供哪些運算了 看可以 03/29 12:47
40F：→ shooter555: 一次運算幾個byte 再來拆loop 畢竟很多餘數特例 03/29 12:48
41F：→ shooter555: 不過講到這個就要完全捨棄可維護性了 在加速部份 03/29 12:51
42F：→ shooter555: 每個迴圈運行的時間不低於三十分鐘 那的確可以捨棄掉 03/29 12:59
43F：→ shooter555: 展開的時間了 03/29 12:59
44F：→ shooter555: 但如果這個function是不到一毫秒執行一次可能會有差 03/29 13:01
45F：→ shooter555: 平行化也不是這麼好用 畢竟還要考慮到race condition 03/29 13:06
46F：→ shooter555: 三十分鐘這麼長的確可以拆幾個thread來跑 但必須確保 03/29 13:08
47F：→ shooter555: 些來的資源不共用 或要另外lock 03/29 13:08
48F：推 ShenJing: 推解釋，有所收穫 03/30 01:18
49F：→ loggan: 有問有人知道內文提到的教科書是？ 03/30 11:43
50F：推 s0914714: 如果那麼在意效能應該是不要用(原生的)Python 03/30 17:25
51F：推 kqalea: 我認同，看看VPP DPDK 05/05 10:50
52F：→ kqalea: 我更覺得 LLVM Backend 是更好更理想的解法 05/05 10:51