自從編程語言誕生以來，人們常常就哪種語言速度最快的問題爭論不休。無論是嚴肅的科學研究，還是深夜酒吧的喧囂，都不乏關于這個話題的爭執。文本不打算就這個問題展開討論，我們不妨從一個更高的層面來看一看這個問題：

如何比較兩種截然不同的編程語言的性能。為了進行有意義的比較，我們必須使用兩種編程語言實現一系列測試程序，運行基準測試，然后再比較最后的結果。

實際上，這種比較的難度很大，有時甚至非常費時費力。盡管問題本身看起來很簡單，但大量可能出現錯誤的地方會導致一無所知的性能測試員遭遇坎坷，有時即使非常了解也無濟于事。

01 等效的實現？

為了公平地比較兩種語言的實現，編寫出來的程序的質量應該達到同等水平。也就是說，必須由某位對兩種編程語言以及領域知識的掌握程度大致相同的人來編寫程序。這本身就很難。如果由不同的人來編寫實現，那么他們可能會選擇不同的算法來解決問題，這樣的性能比較就不再是編程語言本身的問題，而是每位程序員選擇的編程方法的問題。

即使兩個實現都是由同一個人使用相同的算法編寫的，仍然存在其他問題。通常，每個人都有自己擅長的語言。因此，他們會選擇自己喜歡的語言提供更快的實現。這就會引發偏差，因為這樣的性能比較衡量的不是編程語言本身，而更多的是程序員。這類的測試適合尋找易用性與生產力的差異，但對比較性能而言則不合適。

因此，你可能需要評估許多專業程序員已經編寫好的程序。這是一個很好的方法，但有時即使是經驗豐富的研究也會出錯。有一篇論文試圖通過這種方法比較不同的編程語言的性能和效率。

他們的測試結果表明，某個程序用C實現比C++實現快30%。這個測試結果影響了整個論文的基調。按照這個論斷，假設將所有 C 源代碼的文件擴展名 .c 改為.cpp并重新編譯，應該能得到大致相同的結果（可能會有幾個百分點的誤差）。所以我們只能得出以下結論（按照可能性從高到低排列）：

C++版本的代碼比較差；

測試方法有明顯的瑕疵；

與C相比，該編譯器對C++的性能有重大的負面影響。換句話說，上述呈現的差異并非來自編程語言本身。

02 測量的難度

還有一個很大的問題是，如何測量某個程序的性能。一種常見的方法是連續運行多次測試，然后執行如下操作：

處理異常值：去掉兩個極值（即最慢和最快的測量值）；

計算剩余數據點的平均值和/或中位數；

比較不同程序之間的結果，速度最快的程序獲勝。上過統計課程的人可能還記得如何計算標準差。這種方法看似合理且嚴謹，但其實包含多個系統誤差。其中最大的問題涉及測量中的噪聲。

大多數基本的統計工具都會假設誤差呈正態分布，平均值為零。如果測量的是溫度或速度之類，則這個假設是合理的。然而，對于編程語言的性能測量來說，這個假設并不合理。程序的運行時間包括實際上花費在解決問題上的時間，以及來自操作系統中斷、磁盤訪問等方面的開銷。如果我們假設噪聲為平均值為零的高斯噪聲，那么這意味著計算機有一些未知的過程，可以讓程序的運行速度超過完全無噪聲時的情況。這當然是不可能的。這里的噪聲肯定不是高斯噪聲，因為它永遠不會出現負值。

事實上，最接近柏拉圖式理想答案的測量結果就是最快的，因為這種情況下來自系統噪聲的干擾最少。這樣的測量結果會被上述第一步操作“處理異常值”刪除。有時，采用合理的、現成的措施只會讓事情變得更糟。

03 統計的難度更大

暫時撇開這一點不談，我們假設我們獲得了兩個程序的性能測試結果，且這個結果看似確實“很高斯”。數值分析表明，1號語言的運行花費了10秒，而2號語言花費了9秒。二者的差異為10%，因此我們就可以得出結論：2號語言的速度更快。這個結果正確嗎？

很遺憾，不正確。

右邊的那個更快，對不對？也許？大概？可能？為了正確回答這個問題，我們需要回顧一下大學學習的統計知識。首先，提出零假設，即假設兩個程序沒有性能差異。接著，計算這兩次測量結果來自同一個概率分布的概率。

如果概率非常小（通常為5%），則可以推翻零假設，從而證明其中一個程序比另一個快。這種方法叫做學生t檢驗，常用于大量數據的統計。請注意，測試的某些實現會假設數據符合高斯分布，如果你的數據呈現其他形狀，則結果可能并不可靠。

這種方式適用于一個程序，但嚴格的測試需要包含多個程序。這些評估也有一些統計方法，但會非常復雜。具體的做法留給讀者自行查閱。

04 所有計算機的對齊都是雙刃劍

雖然統計非常難，但幸運的是計算機很簡單，因為它們具有確定性、可靠，而且合乎邏輯。例如，如果在一個程序中添加一條NOP指令，則結果可能只是多了一個指令周期，對性能的影響小到無法測量。

但是，如果你非要測量，那么結果可能會讓你陷入不解和困惑。這個小小的改動有時會讓程序的運行時間增加10%（甚至更長），但也有可能縮短10%。你沒看錯，這類看似無意義的工作可以加快程序的運行速度。如果是第一次遇到這樣的問題，你可能壓根不會相信。

那么，問題在于，是否有可能讓CPU加倍努力，讓程序更快地運行呢？答案為否。實際的指令根本無關緊要。重點在于代碼的對齊。代碼在內存中的不同位置會影響其性能特征。

如果一段經常被執行的循環跨越了緩存邊界，它就會變慢。將其移動到不跨越邊界的地方就能加快其速度。NOP指令并不一定要放在循環內，只要它能將整個代碼塊向上或向下移動，就可能導致這種差異。

假設你以非常嚴謹的統計方式測量了兩個程序。如果二者之間的性能差異低于10%，則我們就無法斷言哪個程序更快，除非你使用的測量方式能夠消除對齊效應。

05 這是關于機器的性能測量，而不是語言

隨著程序的運行速度越來越快，優化經歷了一個有趣的階段轉變。一旦性能達到一定水平，系統就不再關心編譯器和CPU如何才能加快程序的運行速度。相反，變成了程序員如何盡可能有效地利用CPU，例如將數據排列成方便處理器處理的布局等。

這意味著用基于硬件的原語替換基于語言的原語。某些圈子采用的優化方式非常奇怪，程序員甚至知道他們的循環應該被優化成哪些SIMD指令，然后他們會不停地修改代碼，直到實現這種優化。其實，這種優化已經與編程語言本身的功能沒有絲毫關系了。

這就是為什么C和Fortran之類的語言仍在許多性能基準測試中名列前茅的主要原因，但這些技巧并不限于這些語言。幾年前，我開發了一款規模非常大的Java應用程序，該應用程序經過了非常徹底的優化。

其內部由整數數組組成。最常執行的路徑中沒有類，甚至沒有Integer對象，基本上就形同于在Java語言內部重塑了C語言。其實，幾乎任何編程語言都可以有類似的實現。

它們之間的性能差異主要取決于每個編譯器的優化器。即便使用相同的編程語言，也會產生截然不同的性能結果，更不用說不同的編程語言了。因此，聲稱某一種編程語言在性能上有明顯的優勢都是不合理的，因為說到底都是內聯匯編程序。

原文鏈接：

https://nibblestew.blogspot.com/2021/02/why-most-programming-language.html？m=1

編輯：jq