Why Java Will Always Be Slower than C++
by Dejan Jelovic
為什么Java永遠比C++慢？
耍過Java程序，或者用Java碼過程序的人都曉得，Java要比用C++寫成的原生程序要慢。這是咱用Java時已經承認的事實。
不過，很多人想要說服我們說這只不過是暫時的，他們說Java從設計上來講并不慢，相反，只是現在的JIT實現相對比較嫩，有很多能優化的地方JIT并沒有優化到，拖了后腿。其實不然，不管JIT們多牛，Java永遠要比C++慢。
我想說...
宣揚Java不慢于C++的人往往是覺得，（語法）嚴格的語言，可以讓編譯有更大的優化空間。因此，除非你想做人肉編譯器優化整個程序，否則通常都是編譯器做得更好。
這是真的。在數值計算領域，Fortran仍然勝于C++，的確因為它更嚴格。不用擔心指針瞎攪和，編譯器可以更安心地優化。C++想打敗Fortran的唯一辦法，就是好好設計一個像Blitz++那樣的庫。
測試...
Java可以跟得上C++的地方，就是基準測試。計算起第N個斐波納契數，或者運行起Linpack，Java沒理由不跟C++跑得一樣快。當所有的計算都放在一個類里，并且只使用基本的數據類型，比如說int或者double時，Java編譯器的確能跟得上C++的腳步。
事實...
當開始在程序中使用對象的時候，Java就放松了潛在的優化。這一節會告訴你為什么。
1. 所有的對象都是從堆里分配的。
Java從棧里分配的，就只有基本數據類型，如int，或者double，還有對象的引用。所有的對象都是從堆里分配的。
當有大量語義上是一回事的對象時，這不成問題。C++同樣也是從堆上分配這些對象。但是，當有值語義不同的小對象時，這就是一個主要的性能殺手。
什么是小對象？對我來說，就是迭代器們。在設計中，我用了很多迭代器。別人可能會用復數。3D程序員可能會矢量或者點類。處理時間序列的人可能會有時間類。使用這些類的人，無一例外地討厭把不費時間的棧上分配換成花費固定時間的堆上分配。假如把它放在一個循環里，就變成了O(n)對0了。如果再加一層循環，沒錯，又變成O(n^2)對0了。
2. 大量的轉換。
得益于模板，好的C++程序員甚至可以寫于完全沒有轉換的牛程序。不幸，Java沒有模板，所以Java代碼總是充滿了轉換。
對于性能，它們意味著什么？呃，在Java里所有的轉換都是很費時的動態轉換。多費時？想想你可能會怎么樣實現轉換的：
最快的方法就是，給每一個類賦值一個序號，然后用一個矩陣來描述任意兩個類是否相關的。如果是的話，需要給指針加上多少的位移才能進行轉換。這種方法的偽碼看起來應該是這樣的：
DestinationClass makeCast (Object o, Class destinationClass) {
Class sourceClass = o.getClass (); // JIT compile-time
int sourceClassId = sourceClass.getId (); // JIT compile-time
int destinationId = destinationClass.getId ();
int offset = ourTable [sourceClassId][destinationClassId];
if (offset != ILLEGAL_OFFSET_VALUE) {
return <object o adjusted for offset>;
}
else {
throw new IllegalCastException ();
}
}
好一堆代碼。這只是一個簡單的情景——用矩陣來表示類的關系浪費了一部分內存，沒有哪個成熟的編譯器會這樣子做。他們會使用map或者遍歷繼承樹，這樣會變得更慢。
3. 攀升的內存占用。
Java程序儲存數據占用的內存大概是相當的C++程序的兩倍。原因如下：
1. 啟用了垃圾收集的程序一般都比不使用垃圾收集的程序多花50%的內存。
2. 本來C++里在棧上分配的對象，到了Java就在堆上分配了。
3. Java對象比較大，因為所有的對象都有一個虛表，還要加上對（線程）同步的原生支持。
大的內存映像讓程序更大概率被放到磁盤的交換區去。沒有什么比交換文件更慢的了。
4. 缺少更細致的控制。
Java原來就是作為一種簡單的語言來設計的。很多在C++里讓程序員控制細節的特性在Java里都被一腳踢開了。
比如說，在C++里可以改進引用的位置(?)?；蛘咭淮紊暾埡歪尫藕芏鄠€對象?；蛘哂弥羔標Ｒ恍┬〖记桑斓卦L問成員。
5. 沒有高層次的優化。
程序員處理高層次的概念。而編譯器處理剩下的低層次概念。對于程序員來說，一個叫Matrix的類就代表了比一個叫Vector的類更高層次的概念。而對于編譯器來說，這些名字都是符號表的一個入口。他們只關心類里面有哪些函數，函數里面有哪些語句。
這樣想一下，比如說要實現一個exp(double x, double y)函數，計算出x的y次冪。對于一個編譯器，它能只看一下這個函數，然后指出，exp(exp(x, 2), 0.5)可以優化成x自己嗎？當然不行。
編譯器能做的優化只是語句層面的，而y是在編譯器里面的。即使程序員知道兩個函數是對稱的，可以把它們都消去，或者函數的調用順序只是相反的，除非編譯器能只瞄一下語句，然后指出來，不然優化是不可能完成的。
所以，如果想要完成一個高水平的優化，必須存在某種方法，可以讓程序員來告訴編譯器優化的規則。
沒有哪個流行的程序語言/系統可以做到這點，至少已知的方法，比如微軟承諾的智能語言，都不能。即便如此，在C++里可以用模板元編程來實現對高層次對象的優化。臨時消除，部分求值，對稱函數調用的消去，和其它可以用模板實現的優化。當然，不是所有的高層次優化都可以這樣做。并且實現這些東西相當麻煩。但是大多數都可以完成，有人已經用這些技術實現了好些時髦的庫。
不幸的是，Java沒有任何元編程的特質，因此在Java中不會有這種高層次的優化。
所以...
由于存在這種語言特性，Java不可能達到C++這種速度。這相當程序上暗示了，對于要求高性能的軟件和競爭激烈的COTS舞臺上，使用Java不是一種明智的選擇。但是因為它和緩的學習曲線，它的容錯，和它龐大的標準庫，所以適合開發中小型自用和定制軟件。
附記...
1. 有人向James Gosling（誰？google之...）提交了很多可以改進Java性能的語言特性。文本在這里。不幸的是，Java語言已經有四年沒有改動過了，所以看起來這些提議似乎不會在一夜之間被實現。
2. 最有可能往Java里加入泛型的是Generic Java。又很不幸的是，GJ只是通過在編譯時把所有類型信息去掉來支持泛型。所以最后面執行環境看到的，仍然是緩慢的轉換。
3. 垃圾收集的FAQ包含了關于垃圾收集慢于定制分配器的信息（上面第四點）。
4. 這里是一篇宣稱垃圾收集比棧分配的快的文章。但是它的要求是物理內存必須是程序實際需要的內存的七倍之多。還有，它描述的是一種stop-and-copy（是不是那種執行到一半，然后停下來，把內存拷到另外一塊內存，同時清除垃圾的那種方法？），而且還不是并發的。
反饋...
我收到很多關于這篇文章的反饋。附上一些典型的評論，還有我的回答：
“你還忘記了指出在Java里所有的方法都是虛方法，因為沒有人會加上final關鍵字。”
事實上，不使用final關鍵字不是問題的關鍵所在，使用者才是。同時，虛函數也沒有問題，但是卻失去了優化機會。自從JIT們知道怎么樣內聯虛函數，這就變得不那么顯著了。
JIT可以內聯虛函數，所以Java可以比C++更快。
C++也可以使用JIT編譯。不信的可以看看.NET的C++編譯器。
到最后的時候，速度并不重要。電腦浪費了大部份時間在等待用戶輸入。
速度仍然很重要。我仍然在等我的筆記本啟動起來，我在等我的編譯器停下來，我還要等Word打開一個超長的文檔。
我在一個金融公司工作。有時候我必須對一個很大的數據集進行模擬。速度在這種情況下都很重要。
有些JIT可以在棧上分配一些對象。
當然，一些。
你的轉換代碼看起來很丑。可以在類的繼承層次上檢查類。
首先，這樣只比矩陣查找快一點點而已。
第二，這樣只能查找類，類只占多少？低層次的細節往往是通過接口來實現的。
哈，那么我們都應該使用匯編？
不是的，我們都要使用對業務有用的語言。Java提供了龐大的標準庫，讓很多任務變得容易，因此Java是偉大的。它比其它所有的語言更容易移植（但并非100%可移植——不同的平臺有不同問題）。它具有垃圾收集機制，簡化了內存管理，同時也讓某些構造如閉包可實現。
但是，同時，Java和所有的語言一樣，也有瑕疵。在值語義的類型上缺少支持。它的同步并不是很有效率。它的標準庫建立在異常檢查之上，把實現拖進了接口。它的性能可以更好。它的數學庫有些惱人的問題。諸如此類。
這些缺憾都是大問題嗎？看你用它做什么。因此，在幾種語言里，連同它的編譯器以及可以選擇的類庫里選擇對你的工程有利的一種。
回復 更多評論