推 aecho:我覺得越快的機器，那5%應該會變小才對… 05/24 06:58
→ aecho:如果要做的事情都是bytecode經JIT轉native 05/24 06:58
→ aecho:沒有理由在越快的機器上，差距越大。我反而覺得差距會拉近。 05/24 06:59
推 aecho:因為轉換所需要的動作應該是固定的，不會因機器變快而變多。 05/24 07:02
※ 引述《lgd1008 (lgd1008)》之銘言：
: 這個問題10年前問還有道理, 沒想到2011年了還有人問..
我想只要Java沒消失，十年後還是會有人繼續問。
: Java效能的瓶頸多在I/O, 資料需要頻繁地進出VM, marshalling. 為了I/O效能, 你可以
: 使用JNI, JNI本來就是Java考量所在; 相反的,若為了彈性或簡潔, 你也可以在Java裡執行
: Java Script. 這些東西都提供你做選擇.
那只是一個比較明顯的瓶頸，個人看法是Java永遠也快不起來。
為什麼？因為Java常態是編譯成bytecode給VM跑，VM再做JIT轉成原生碼給CPU跑，
永遠有一個overhead在。即使JIT美妙到可以有直接編譯成原生碼給CPU跑的效能的95%，
差那5%代表的是什麼？代表在同一時脈下，Java就是跑輸直接編譯成原生碼的東西5%。
CPU時脈愈快，那5%換算出來的絕對差距也就愈大。何況現實應用中，從來也沒只差5%。
一開始的差不多，在愈快的機器上差距愈大。差以毫釐，失之千里。
Java的優點從來也不在效能上。
何況garbage collection一跑，整個系統效能就頓下來了。
Java能靠JIT與最佳化在效能上得到長足進步的美夢，從十幾年前就已經在吹泡泡。
但是你自己仔細算一算，不管什麼東西，只要是靠CPU跑的，最終的效能計算還是得
回到CPU的指令集最佳化上，每個指令需要多少時間跑，有多少個管線能同時處理。
在每個步驟上東差一點、西差一點，整體累積起來就慢了許多。
何況這些年看來，即使拿MSFT的VC++編譯器來看，都看得出來他們在機械碼效能最佳化
上還持續改進著。反觀Java JIT，生出來的X86 code一反組譯出來看，它真的有在進步
嗎？說.NET framework的JIT愈做愈好是看得到的，說Java VM的JIT愈來愈好就比較看
不出來，畢竟Sun腳步停滯那麼久，被Oracle併購後又是那樣子。
Java的效能美夢已經被吹噓到讓許多人忽略了計算機結構上的根本道理了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.10.18