※ 引述《Lordaeron (Terry)》之铭言： : 你实在是爱断章取义, 我一直都只有在讲需要lock 的情形, 需要lock 时 说断章取义真的远不及阁下了. : 不就是需要thread safe? 还是你习惯性写thread unsafe 的程式我也没意见. 你给的资料, 最多只能看到 sync/lock operation 在不同情况下的 degrade. 把 sync/lock operation 的 degrade 程度说成整个 application 的 degrade 程度, 这真是可笑之至 Thread safety 的问题你看不懂的话请你乖乖再去读别人写的是什麽. 我指出的是在正常的程式里面, 根本不会有像你那些 link 的测试或 资料那麽多 sync/lock. 离题一点, code 要 thread safe, 还有很多方法, 不用 lock 就是写 thread-unsafe 程式? 你别贻笑大方了吧. : 最後, 你最爱的lock/sync 的 performance 一直有在改进中, 哪麽就请你 "你最爱" 我可不知道那里得出来的结论. : 指出现在是不是像你所说的, lock/sync 最多只掉5% 罗. 又来断章取义喽. 一直在说的是整体 performance 掉多少, 你就把别人说的硬 改写成 "lock/sync 最多只掉5%" : 另外, 我差点忘了, 我只是要指出, 将问题单纯化到用机器来解决, 像你常讲的, : 加个ram 买>2GB 的memory, 换64 bit 都不是问题. : 问题是换个64 bit 就掉15%, 加个CPU 也没辨法要回来. 很有趣耶. 假设 1CPU -> 2CPU 可以给我 150% processing power (蛮正常的数值) 换 64bit 掉15% 1CPU(32bit) vs 2CPU (64bit) = 1 : 1.275 你自己说的数值都解释不了为什麽加个 CPU 要不回来. 从来没有人说所有问题都能单纯用机器解决, 你才真的在 断章取义吧. : 这个你的讲法是行不通的而已. 不是所有情况都合用, 就是行不通? 我在另一篇也有提过, 你要明白自己 app 面对 的 bottleneck 是什麽而用合适的方法去解决. 很不幸, 就是有很多application 的困难在於那区区 1.xGB memory 不足够. : 而我知道你公司很大, 随便都可以给你要个10GB, 8GB 来给你的AP用. : 而我遇到的, 可没辨法, 申请单填了还不见得会过. 开始扯一堆有的没的来酸了吗? 这世界就是有很多很多公司买得起 >4GB RAM 的 server. 你大可继续当鸵鸟把现实世界当成是其他人在发梦, 而只有你身处 的才是现实世界 : but 我记得, 路透的东西, 要用C++ 来写比较好吧. 扯这些只显出你自己无知而已. Thomas Reuters 的 RFA 是人家提供的, 你要是觉得只有 C++ 才能写 Reuters 的 data feed etc, 你就去问问 Reuters 为什麽 要自甘堕落提供 Java 的 lib 喽. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.238.156.185 ※ 编辑: adrianshum 来自: 61.238.156.185 (03/04 18:47)