Re: [問題] thread會導致程式執行反而變慢嗎？

看板java作者AmosYang (LetMeGoogleThatForYou)時間15年前 (2010/04/01 17:35)推噓4(4推 0噓 9→)

留言13則, 5人參與討論串4/4 (看更多)

補充一些碎碎念 XD multithreading 與整體 performance 之間的關係比五星物語的設定還複雜易言之，當你在研究 perf. 問題時，threading 就像超聖水一樣，喝下去是 nerf 還是 buff 沒有人知道更有趣的是，當你在處理 Java / .Net 這種與 native code 中間隔一層東西的東西時, WYSIPNWYG XD "What you see is probably not what you'll get." 因為 Java VM / .Net CLR 跑的 managed thread 並不一定直接對應到 native thread. 以 .Net 4 來說現在的確是一條 managed thread 是包在一條 native thread 裡跑，但根據正在進行的討論，這在 .Net 5 可能會改變以 Java 來說，可以參考 http://java.sun.com/docs/hotspot/threads/threads.html 這篇雖然是以討論 Solaris 為主，但最主要的想法就是說明你在 JVM 裡看到的東西與最後 OS kernel 裡在跑的東西可能差了十萬八千里是故，研究 multithreading 本身是一回事，如果要研究 multithreading 與 perf. 之間的愛恨情仇，你會需要更多的背景知識不然的話，就像 willieliao 講的，有 X 個 CPU (logical CPU core) 就最多開 X 條 thread 吧 XD ※ 引述《willieliao (Willie Liao)》之銘言： : Thread本身有overhead，以這種沒有io／network等待的純記憶體內運算來說 : 最快的方法是用Thread pool，以原po四核心的電腦 : 用同樣的四條Thread各運算250次會比開1000條 : Thread運算一次或用同一條Thread算1000次要快的多。 : ※ 引述《yamamura (sadako)》之銘言： : : 請問我有遺漏哪些重點呢？為什麼會這樣？ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 65.87.177.87 手上程式還在 compile... 來多念一點關於 perf. tuning / optimization 如果你沒有看過 Michael Abrash 寫的 The Zen of Code Optimization 停止你手上正在做的 optimization ，先去把那本書讀完 (讀前半部就可以了，後半部在講如何 profile 80486/DOS3.0 的東西 XD) 以前在這個板上有提過 optimization 的大方向，現在換個角度從下往上看 1. 「鑽研 ++i 與 i++ 哪個比較快」這種 micro-optimization 與自慰差不了多少把你的時間用在研究把你的演算法的 big-O 往下降一級比較有用 2. 如果你會花時間讀我寫的東西，且你認為你自製的 cache 能表現得比 OS / app-tier 內建的 cache 還要好， YOU ARE WRONG, period. 3. Application performance 有八成來自於 perception. 剩下的兩成才是 big-O 4. Loops. It's always about loops. (以上皆為現學現賣 XD 這兩天有幸能與寫 Debugging Microsoft .NET 2.0 Applications ISBN-13: 978-0735622029 這本書的 John Robbins 本人瞎扯/學習/討論 XD 看了一些頗精采的 debug / optimization 案例後的心得 WinDBG 在我手上像木棍，在他手上像光劍那種… Boxer/梅原大吾等級的神人… XD) ※ 編輯: AmosYang 來自: 65.87.177.87 (04/01 18:32)

→

ogamenewbie

04/01 19:58, , 1^F

04/01 19:58, 1^F

→

AmosYang

04/01 20:26, , 2^F

04/01 20:26, 2^F

→

ogamenewbie

04/01 20:30, , 3^F

04/01 20:30, 3^F

啊，那邊沒有寫得很清楚，應該修正為如果你會花時間讀我寫的東西 (代表你的查克拉還不夠強大) 能用 OS / app-tier 內建的 cache 機制就乖乖用如果你認為你自製的 cache 能表現得比 OS / app-tier 內建的 cache 還要好 YOU ARE WRONG, period. (最後只會事倍功半而已) 這段的由來是因為看了幾個 case, 苦主都是自作聰明自己發明一套 cache 機制卻對 OS / .Net 沒有很深入的了解 (例如，了解 gen 0 1 2 heap / GC.Collect() 真正如何運作) 導致最後 perf. 大爆炸而最後 fix 很簡單: comment out 苦主自己發明的 cache 機制就好了 XD 這段的用意並不是說要完全捨棄所有的 "自製 cache 機制" 而是指「在發明你自己的 cache 機制前，務必要從頭到尾完全了解整個 technology stack」不然的話只會自找苦吃 ※ 編輯: AmosYang 來自: 65.87.177.87 (04/01 20:55)

→

AmosYang

04/01 20:57, , 4^F

04/01 20:57, 4^F

推

ogamenewbie

04/01 21:31, , 5^F

04/01 21:31, 5^F

有一點時間，來簡述一個上面所講的自殘 cache 機制的 .Net 案例苦主的機器上有數十 GB 的記憶體，但卻沒事就丟 OutOfMemory (OOM) exception 出來最後發現，他老兄自作聰明地開無雙 byte[] 來 cache 一些大檔案當然，在測試的一切順利，一上 production server 時就爆炸了奇妙的是，整個機體上記憶體還很多，為什麼 OOM 炸個不停? 原因很簡單，他開的無雙 byte[] 都是動輒數百 KB 甚至上 MB 沒兩三下就把 gen 2 heap 打了個亂七八糟，fragmentation 慘不忍睹最後就 OOM 炸個不停最後解決辦法很簡單， file cache 就讓 OS / .Net 來做就好了註解掉苦主的無雙 file cache 後，天下太平雖然在處理某幾個檔案時會比之前慢，但整體 server 的效率卻提昇不少 (因為沒有 OOM exception 來扯後腿) 事後苦主在了解整件事的來龍去脈後，有試著重寫他的無雙 file cache 最後效率並沒有比 OS / .Net 的 cache 好多少 (大約 1~2%) 並不值得多花成本去維護無雙 file cache 的程式碼 senior programmer 一小時的時間成本要上百美元多買幾條 RAM 還便宜點 XD 套一句之前在 PLT (還是 OOAD?) 板看到的名言的翻譯來收尾 XD 未成年就這麼優，是一切邪惡的根源 "Premature optimization is the root of all evil." -- Donald Knuth …有空再來補述 perception vs. performance 之間的愛恨情仇 XD ※ 編輯: AmosYang 來自: 65.87.177.87 (04/02 20:35)

→

AmosYang

04/02 20:36, , 6^F

04/02 20:36, 6^F

※ 編輯: AmosYang 來自: 65.87.177.87 (04/02 20:48)

→

AmosYang

04/02 20:48, , 7^F

04/02 20:48, 7^F

推

willieliao

04/03 00:01, , 8^F