※ 引述《adrianshum (Alien)》之铭言： : ※ 引述《Lordaeron (Terry)》之铭言： : : link 在这: : : http://www.research.ibm.com/people/d/dfb/talks/Bacon98ThinTalk.pdf : : 你可以去跟作者PK 一下. : 当中谈到的和讨论有关的只有 Locking overhead frequently 25-50%. : 这建基於slide 的上一句: Libraries must be thread-safe. : 问题在於 Java world, 这个 assumption 还适用吗? : 在 Java 的开发, 很多时候 lib 已经提供非 thread-safe 的 alternative, : (ArrayList vs Vector, StringBuilder vs StringBuffer etc), "Libraries : must be thread-safe" 早已不是金科玉律, 为的正是 performance. : 用家需要在 multi-thread 下使用, 才自己去做 (用 thread-safe counterpart, : 或自己 sync/lock, 或 use separate instance etc) : 另外你给的 slide, 当中提到的就是如何用 thin-lock 来取代 heavy-weight : synchronized. java concurrent lib 就是提供这类 locking strategy : 的. 再者而 lock/sync 的 performance 一直有在改进中. : 要是你继续抱着好几年前的想法或资料, 当成现在的情况, 就等如某些人还 : 是以为没有公司有钱买 > 2G 的 server 或没有 application 可以用到 > 1G : 的 memory, 所以 64bit 的 larger address space 是多余的 一样脱离现实. 你实在是爱断章取义, 我一直都只有在讲需要lock 的情形, 需要lock 时 不就是需要thread safe? 还是你习惯性写thread unsafe 的程式我也没意见. 最後, 你最爱的lock/sync 的 performance 一直有在改进中, 哪麽就请你 指出现在是不是像你所说的, lock/sync 最多只掉5% 罗. 另外, 我差点忘了, 我只是要指出, 将问题单纯化到用机器来解决, 像你常讲的, 加个ram 买>2GB 的memory, 换64 bit 都不是问题. 问题是换个64 bit 就掉15%, 加个CPU 也没辨法要回来. 这个你的讲法是行不通的而已. 而我知道你公司很大, 随便都可以给你要个10GB, 8GB 来给你的AP用. 而我遇到的, 可没辨法, 申请单填了还不见得会过. but 我记得, 路透的东西, 要用C++ 来写比较好吧. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.45.250.249