Re: [討論] Python 3.10將加入Switch-Case語句
※ 引述《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
--
新詩練習:新鮮。踩破初春裡的狗大便;不經意的滄桑,滿溢著嫩黃的喜悅。
--
推解釋詳細
推
好奇請教一下,如果捨棄 for loop,改成將 subarray 傳遞
至 function,而後再回傳,如此一來在優化上是否更好做?
再多問些,如果再加上 map 呢
如果你前提是每個 for-loop 拆出程式分開跑當然效能好
@yislin, 你給的條件對我來說比較像是維護性的問題.
,但前篇文章前提是同支程式。
此外並不是講職稱就能把你的話直接變成正解,技術要合理
才能。
維護性也蠻重要的, 一味優化的結構很恐怖, 隔天就看不懂.
我並沒有要反駁說這篇哪個做法是錯的,因為
這篇又多加了幾個前提,那解法又更不同。
@alihue, 其實我只是「從效能的觀點」來說... XD
我自己也在每天幾千 QPS 的系統工作,但我不會認為我是正
解
從維護性來說, 我的經驗也告訴我, for + if 少用為妙.
因為出錯的時候真的很難 debug, 尤其一群猴子合作的情況
對, 我就是說我們的團隊... XD
我們都直接買64 core的給大家跑 優化有空再做就好了
推
如果要拆來跑的話當然是拆開for loop跟preprocessing
的概念是一樣意思,但是這樣跟用不用if在for loop裡s
cope就完全不同了
沒平行的時候硬要這樣寫就是慢啊
你前提是平行那也沒討論if的必要
台灣主管真敢講 說自己團隊是猴子
真好奇哪家上市公司
看起來你的loop順序不影響結果 那直接做data paralle
l 有幾個entry就拆成幾個job 不是更快?
搞不好人家只是謙虛而已
不是謙虛! 而是... 薪水用鄉民的眼光看, 真的是香蕉等級
data parallelism 是其中的部分考量而已.
而且運算量大的時候, 常見的拆法也不能用.
因為通常也會伴隨 bandwidth 的問題.
bandwith 「不足」... 漏寫.
bandwidth........一直打錯.
同意越接近數學越好維護
指令集的問題就變成要看指令集提供哪些運算了 看可以
一次運算幾個byte 再來拆loop 畢竟很多餘數特例
不過講到這個就要完全捨棄可維護性了 在加速部份
每個迴圈運行的時間不低於三十分鐘 那的確可以捨棄掉
展開的時間了
但如果這個function是不到一毫秒執行一次可能會有差
平行化也不是這麼好用 畢竟還要考慮到race condition
三十分鐘這麼長的確可以拆幾個thread來跑 但必須確保
些來的資源不共用 或要另外lock
推解釋,有所收穫
有問有人知道內文提到的教科書是?
如果那麼在意效能應該是不要用(原生的)Python
我認同,看看VPP DPDK
我更覺得 LLVM Backend 是更好更理想的解法
4
話說我只是想分享一下我前一陣子在 twitter 上面看到的討論 簡短的來說就是某 PL 強者認真的研究了一下 PEP 622,然後提出了質疑。 (對,我知道不是 635 但我只是要分享這件有趣的事情) 先附上原文: TL;DR 是這樣的1
我個人是很討厭很多if-else, 或是switch case. 並不是說不好, 只是很容易出現有些section是code, 有些是function. 案子急一點, 重覆的code就會很多. 幾百個if-else/switch-case就有機會變成上萬行的code. 這個就很阿雜了. 就之前數字區間的code, 我是會往這個方向走12
: : 沒有使用Python不知道生態系如何 : Google App上看到的文章 : 不知道各位大大對Switch加入有什麼看法 :8
討論這麼熱烈 可是各位有點進去把它看完嗎XD Python 3.10 的 Structural Pattern Matching 不是單純的 switch-case 而已 它的 case 裡是還可以放變數給它賦值的(不知道怎麼準確描述 舉個官網的例子,還可以這樣用:22
首Po上面說2006年 PEP 3103就建議實施switch-case語句。但是,在PyCon 2007上的一項民意調查未獲得對該功能的支持後,Python開發人員將其刪除。 沒有使用Python不知道生態系如何 Google App上看到的文章 不知道各位大大對Switch加入有什麼看法
爆
[問卦] python做科學運算,要分享什麼?欸欸 我明天group meeting要分享python科學數值運算小技巧 我目前想到要講的 1. 介紹numpy 2. 不要用迴圈 用numpy 3. 用numba jit編譯35
Re: Re:[情報] 謠言稱AMD在RX7900使用不完整RDNA3 A我是不認同上面講法。架構本身設計是沒有大問題的。 先講dual issue(雙發射),這個在Pentium時代dual pipeline的時候就知道原理了,主要是在有效運用運算單位。實際程式上不可能100%+,甚至50%+都不可能,但就算20%+也是划算的。 GPU的simd thread也是相同的原理,幾十個threads同時使用同樣的運算單位,因為gpu的simd運算單位的使用率是非常低的。 所以registers這些東東早就是夠用了,問題不在這裡。也不是什麼新的指令有bugs不能用,這都有影響,但問題不大。 這一代的問題是,單front end在跑,3Ghz+輕鬆,simd 運算跑,3Ghz+輕鬆。前段,中段,後段,單獨跑都沒什麼問題。但遊戲需要前,中,後一起跑就完蛋了。19
Re: [討論] AI晶片這我來回答吧 AI晶片一般是指用來加速深度學習模型推理的晶片 如果是訓練通常還是利用Gpu 因為生態系比較成熟 那麼深度學習推理時間會耗在哪裡呢 通常就是convolution 或是Gemm18
Re: [新聞] 首款5G iPhone 性能超狂?疑似蘋果A14 處不同cpu架構當然可以比較 只是geekbench在跨架構上的分數不是很公允 (以前似乎有對cache size不敏感的爭議,現在不知道怎樣了) 假設先不管作業系統上的應用體驗 再多兩個條件1) 同TDP 2) 只看bare metal app. 的算力12
Re: [情報] AMD早期路線曝光Zen4確實考慮過單核四線沒記錯的話hyperthreading彼此之間L1 cache依然共用 變成1C4T這樣會導致一個問題就是L1 cache在hyperthreading彼此之間的同步會變得比1C 2T時複雜也會使效能下降 一般來說在HPC如果variable 是可以讓1T算完後就馬上pass給在同一C裡面的另1T(即pip eline 運算,並非CPU instruction pipeline)12
Re: [請益] 只會C++就業難度先講結論,如果只會"c++",而其他甚麼都不會的話,目前確實很難就業 搞影像的現在還是很缺會c++的人才 只是光靠c++這門語言其實沒有多大的意義 簡單來說好了,這是我朋友的親身經歷 他是做影像的6
[北美] Google Full-time SWE team match 求撈前輩們大家好 小弟去年暑假有幸在疫情期間照常在G社實習, 11月拿到了return offer (new grad SWE) 去年年底也順利在UC San Diego畢業了(MS) 即將在今年3月中上工, PA是在Bay Area的Core 最近接到 HR 電話講解team match流程4
Re: [請益] 1660S x2 or 3070 組DL server最近版上出現一些深度學習配單,覺得有一些心得可以分享,省的走冤枉路 就來回一下舊文,我最後拿3070喇 先說結論,3060 cp值最高唯一推薦,再上去建議直接攻頂3090 大部分人買顯卡都很關心效能,所以我看到有些人會拿3070, 3060ti上來問 但是跑深度學習除了效能以外,VRAM大小以及資料讀取的IO時間都會影響training效率X
[硬體] 蘋果首推自製M1處理器於Mac電腦 採Arm架蘋果首推自製M1處理器於Mac電腦 採Arm架構、台積電代工 蘋果終於要擺脫英特爾了嗎?蘋果首款自製M1處理器採用Arm架構,正式於2020年11月11 日發布,將應用於Mac三款新個人電腦產品:MacBook Air、MacBook Pro及Mac mini。新 款13英寸MacBook Pro的起價為1,299美元。2
Re: [開箱] 驀然回首 技嘉VEGA56庫存品開箱Vega當初號稱有4大亮點。 1)最先進的gpu記憶體架構(cache, hbm2) 2)Next Generation Geometry Pipeline(次世代幾何引擎)