Re: 64 bit 有比32 bit 好? 還是看圖吧.
※ 引述《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
討論串 (同標題文章)