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

看板java作者 (LetMeGoogleThatForYou)時間15年前 (2010/04/01 17:35), 編輯推噓4(409)
留言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)

04/01 19:58, , 1F
?... 為什麼是 period?
04/01 19:58, 1F

04/01 20:26, , 2F
↖ ?
04/01 20:26, 2F

04/01 20:30, , 3F
第 65 行 YOU ARE WRONG, period.
04/01 20:30, 3F
啊,那邊沒有寫得很清楚,應該修正為 如果你會花時間讀我寫的東西 (代表你的查克拉還不夠強大) 能用 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)

04/01 20:57, , 4F
補述了一段,希望有講得更明白些 :)
04/01 20:57, 4F

04/01 21:31, , 5F
原來如此. (為那些苦主默哀)
04/01 21:31, 5F
有一點時間,來簡述一個上面所講的自殘 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)

04/02 20:36, , 6F
補述一個 未成年就這麼優 的案例… XD
04/02 20:36, 6F
※ 編輯: AmosYang 來自: 65.87.177.87 (04/02 20:48)

04/02 20:48, , 7F
在補述裡補述另一小段…
04/02 20:48, 7F

04/03 00:01, , 8F
五星物語在我國中的時候就很紅了,現在變成35歲的大叔
04/03 00:01, 8F

04/03 11:31, , 9F
突然發現我離「大叔」也不很遠了… 哭哭
04/03 11:31, 9F

04/04 03:11, , 10F
看完之後決定回去好好重念OS
04/04 03:11, 10F

04/04 21:14, , 11F
妖魔化Java板就交給吾輩,樓上好好照顧正妹同學就好 XD
04/04 21:14, 11F

04/10 03:46, , 12F
是 PLT, 語出 lukhnos
04/10 03:46, 12F

04/17 06:46, , 13F
感謝樓上補述 :D
04/17 06:46, 13F
文章代碼(AID): #1Bj6ZTjD (java)
文章代碼(AID): #1Bj6ZTjD (java)