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

[AmosYang (LetMeGoogleThatForYou)]

補充一些碎碎念 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:?... 為什麼是 period?
→ AmosYang:                        ↖ ?
→ ogamenewbie:第 65 行 YOU ARE WRONG, period.
啊，那邊沒有寫得很清楚，應該修正為

  如果你會花時間讀我寫的東西 (代表你的查克拉還不夠強大)
  能用 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:補述了一段，希望有講得更明白些 :)
推 ogamenewbie:原來如此. (為那些苦主默哀)
有一點時間，來簡述一個上面所講的自殘 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:補述一個 未成年就這麼優 的案例…                   XD
※ 編輯: AmosYang        來自: 65.87.177.87         (04/02 20:48)
→ AmosYang:在補述裡補述另一小段…
推 willieliao:五星物語在我國中的時候就很紅了，現在變成35歲的大叔
→ AmosYang:突然發現我離「大叔」也不很遠了… 哭哭
推 KanoLoa:看完之後決定回去好好重念OS
→ AmosYang:妖魔化Java板就交給吾輩，樓上好好照顧正妹同學就好   XD
推 godfat:是 PLT, 語出 lukhnos
→ AmosYang:感謝樓上補述 :D