补充一些碎碎念 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) 啊，那边没有写得很清楚，应该修正为 如果你会花时间读我写的东西 (代表你的查克拉还不够强大) 能用 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) 有一点时间，来简述一个上面所讲的自残 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 来自: 65.87.177.87 (04/02 20:48)