看板 Soft_Job 關於我們 聯絡資訊
※ 引述《Aurim (Who cares?)》之銘言: : ※ 引述《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的效能美夢已經被吹噓到讓許多人忽略了計算機結構上的根本道理了。 不要只把 VM, GC 算進 overhead, 而不同時考慮他們可能對效能產生的幫助, CPU的指令己是VC++執行時的全部, 但並非 .net, Java執行時的全部 會拿看起來 VM, GC 是 overhead 的情況去看 Java, .net 那怎麼不拿非 VM, GC 存在不可的情況去看 VC++ 呢? 如果你真的完全不想這種可能性, 應該早就值疑上篇測試的結果作假了.. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.9.124
iincho:老實說我不知道爭這個幹嘛,真的用Java比較快現在就不會 05/23 11:57
iincho:很多注重速度的系統通通都是跑native code.. 05/23 11:57
iincho:現實環境就是VM的overhead不可忽略,就算在某種環境VM較快 05/23 11:58
iincho:同樣的機制用native code重寫一定會更快..... 05/23 11:58
lgd1008:推重寫! 若連OS一起重寫還會更快. 05/23 12:19
askeing:我是覺得用途不同自然看得就不一樣,倒是沒啥好爭的 XD 05/23 12:21