※ 引述《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