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

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