PTT評價

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

看板Soft_Job標題Re: [討論] Python 3.10將加入Switch-Case語句作者
Muscovy
(三分熟的鬧鐘)
時間推噓 8 推:9 噓:1 →:42

※ 引述《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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.47.50 (臺灣)
PTT 網址

yislin03/28 00:31推解釋詳細

x906000045603/28 00:32

yislin03/28 00:37好奇請教一下,如果捨棄 for loop,改成將 subarray 傳遞

yislin03/28 00:37至 function,而後再回傳,如此一來在優化上是否更好做?

yislin03/28 00:40再多問些,如果再加上 map 呢

alihue03/28 00:42如果你前提是每個 for-loop 拆出程式分開跑當然效能好

Muscovy03/28 00:43@yislin, 你給的條件對我來說比較像是維護性的問題.

alihue03/28 00:43,但前篇文章前提是同支程式。

alihue03/28 00:43此外並不是講職稱就能把你的話直接變成正解,技術要合理

alihue03/28 00:43才能。

Muscovy03/28 00:43維護性也蠻重要的, 一味優化的結構很恐怖, 隔天就看不懂.

alihue03/28 00:43我並沒有要反駁說這篇哪個做法是錯的,因為

alihue03/28 00:44這篇又多加了幾個前提,那解法又更不同。

Muscovy03/28 00:44@alihue, 其實我只是「從效能的觀點」來說... XD

alihue03/28 00:45我自己也在每天幾千 QPS 的系統工作,但我不會認為我是正

alihue03/28 00:45

Muscovy03/28 00:45從維護性來說, 我的經驗也告訴我, for + if 少用為妙.

Muscovy03/28 00:46因為出錯的時候真的很難 debug, 尤其一群猴子合作的情況

Muscovy03/28 00:46對, 我就是說我們的團隊... XD

paimin03/28 01:17我們都直接買64 core的給大家跑 優化有空再做就好了

taipoo03/28 01:39

handsomeLin03/28 10:53如果要拆來跑的話當然是拆開for loop跟preprocessing

handsomeLin03/28 10:53的概念是一樣意思,但是這樣跟用不用if在for loop裡s

handsomeLin03/28 10:53cope就完全不同了

Murasaki011003/28 10:59沒平行的時候硬要這樣寫就是慢啊

Murasaki011003/28 11:01你前提是平行那也沒討論if的必要

majohnsha03/28 12:27台灣主管真敢講 說自己團隊是猴子

majohnsha03/28 12:28真好奇哪家上市公司

recorriendo03/28 13:33看起來你的loop順序不影響結果 那直接做data paralle

recorriendo03/28 13:33l 有幾個entry就拆成幾個job 不是更快?

j095832208003/28 18:13搞不好人家只是謙虛而已

Muscovy03/29 00:49不是謙虛! 而是... 薪水用鄉民的眼光看, 真的是香蕉等級

Muscovy03/29 00:52data parallelism 是其中的部分考量而已.

Muscovy03/29 00:53而且運算量大的時候, 常見的拆法也不能用.

Muscovy03/29 00:55因為通常也會伴隨 bandwidth 的問題.

Muscovy03/29 00:55bandwith 「不足」... 漏寫.

Muscovy03/29 00:56bandwidth........一直打錯.

vi00024603/29 11:54同意越接近數學越好維護

shooter55503/29 12:47指令集的問題就變成要看指令集提供哪些運算了 看可以

shooter55503/29 12:48一次運算幾個byte 再來拆loop 畢竟很多餘數特例

shooter55503/29 12:51不過講到這個就要完全捨棄可維護性了 在加速部份

shooter55503/29 12:59每個迴圈運行的時間不低於三十分鐘 那的確可以捨棄掉

shooter55503/29 12:59展開的時間了

shooter55503/29 13:01但如果這個function是不到一毫秒執行一次可能會有差

shooter55503/29 13:06平行化也不是這麼好用 畢竟還要考慮到race condition

shooter55503/29 13:08三十分鐘這麼長的確可以拆幾個thread來跑 但必須確保

shooter55503/29 13:08些來的資源不共用 或要另外lock

ShenJing03/30 01:18推解釋,有所收穫

loggan03/30 11:43有問有人知道內文提到的教科書是?

s091471403/30 17:25如果那麼在意效能應該是不要用(原生的)Python

kqalea05/05 10:50我認同,看看VPP DPDK

kqalea05/05 10:51我更覺得 LLVM Backend 是更好更理想的解法