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)
→
04/01 19:58, , 1F
04/01 19:58, 1F
→
04/01 20:26, , 2F
04/01 20:26, 2F
→
04/01 20:30, , 3F
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
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
04/03 00:01, 8F
→
04/03 11:31, , 9F
04/03 11:31, 9F
推
04/04 03:11, , 10F
04/04 03:11, 10F
→
04/04 21:14, , 11F
04/04 21:14, 11F
推
04/10 03:46, , 12F
04/10 03:46, 12F
→
04/17 06:46, , 13F
04/17 06:46, 13F
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 4 之 4 篇):
java 近期熱門文章
PTT數位生活區 即時熱門文章