喜歡和不喜歡Go語言的都喜歡拿性能PK說事.php
流傳比較廣的是benchmarksgame的PK數據: http://benchmarksgame.alioth.debian.org/u64q/go.php算法
在 benchmarksgame 測試中, Go語言的性能已經由以前的很爛到如今和C語言持平或2倍差距以內, 固然還有 3個測試性能差距比較大.編程
具體的緣由我就不細說了, 能夠參考我另外一個文章: Go1.1性能測試報告(和C差距在10%之內) .併發
固然, 不少Go語言黑是歷來不相信Go語言的性能的, 特別是不相信和C差距在10%之內的說法. 不過在這個老外的最新測試結果中, Go的性能又超出了GCC的性能(GCC比clang有一些差距).編程語言
最近, 有另外一個外國的博客評測了各類系統級編程語言的性能, 而翻譯後標題給出了PK的字樣. 內容摘要有2點: D語言很NB(clang的99%性能)和超爛的Go性能(clang的22%墊底).wordpress
這個性能測試結果幾乎是每幾天就一個驚喜, 具體數據請看:函數
1. Go性能是clang的22% (2012.07.24)工具
匿名讀者 寫道 "C/C++已經統治系統編程好久,除了ObjectiveC以外語言都沒法得到很高的關注。有人用多種系統級語言編寫了一樣的地圖生成工具來測試他們的性能,包括D(DMD,LDC,GDC)、Go(GCC-Go,6g)、Haskell(GHC)和Rust。相比C/C++,這些語言都原生支持了諸如垃圾回收這些高級特性,也所以無一能達到C/C++的運行速度。這其中表現最差的是原生Go語言編譯器6g,只有Clang22%的速度,而表現最好的是基於LLVM的D語言編譯器LDC,達到了79%。因爲原生就使用了LLVM編譯,Rust成爲各語言原生編譯器裏最快的一個,但也只達到了45%。從結果來看,D語言必定是首選。因爲D語言許多特性都依賴垃圾回收,若是須要關閉垃圾回收而又要保持良好的使用體驗,則推薦Rust。"性能
Go語言光榮的以22%的成績墊底!測試
連接: 系統級編程語言性能大PK
2. Go性能是clang的51% (2013.07.27)
匿名讀者寫道 "上一篇發的時候,做者優化不夠,如今在幾天的修改之後結果徹底不同了。 C/C++已經統治系統編程好久,除了ObjectiveC以外語言都沒法得到很高的關注。有人用多種系統級語言編寫了一樣的地圖生成工具來測試他們的性能, 包括D(DMD,LDC,GDC)、Go(GCC-Go,6g)、Haskell(GHC)和Rust。相比C/C++,這些語言都原生支持了諸如垃圾回 收這些高級特性,也所以無一能達到C/C++的運行速度。其中表現最好的是基於LLVM的D語言編譯器LDC,與一樣基於LLVM的C編譯器Clang相比,能夠達到它96%的速度。其次是基於LLVM的Rust編譯器,達到了89%。由於LLVM編譯的優化作的太好,即便GCC都只能達到Clang 72%。另外一個使人驚訝的結果是,基於JVM的Scala居然能達到Clang70%的速度。幾乎至關於GCC。 "
由於前一個新聞剛發不久, 就有回覆說原網站數據已經更新. Go語言的性能大約是51%.
這個新聞是是以前的補充, 由於沒墊底也不突出, 也就閉口不提Go語言的性能測試結果了.
國外原網站做者也採用更委婉的說法: Go語言讓人感到驚喜! (不知道51%倒數性能有什麼值得做者驚喜的).
連接: 系統級編程語言性能PK
3. 繼續PK, Go語言性能是69%, GCC是72% (2013.07.30)
4. 繼續PK, Go語言性能是75%, GCC是81% (2013.08.??)
這個數據變化國內的網站沒有都更新. 其中, 還有一些細微的變化過程.
5. Go語言性能是87%, GCC是81%, 終極PK嗎?(2013.08.06)
Compiler Speed(s) %Fastest Clang 0.280 100% LDC 0.281 99% FCC** 0.283 99% Rustc 0.303 92% 6g 0.323 87% G++* 0.330 85% Scala 0.344 81% GCC 0.347 81% LLVM-GHC 0.428 65% GHC 0.546 51% DMD 0.567 49% GCCGO 0.598 47%
國外的原網站: Benchmarking level generation: Go, Rust, Haskell and D (and now Scala)
結尾
其實, 我很想將這個PK中各個語言的性能變化曲線畫出來, 特別是Go語言怎麼從22%倒數第一 到87%中等偏上的走勢. 我相信其餘語言也有相似的變化過程, 可是不會像Go語言變化的這麼 有喜感.
我想致使Go語言巨大變化的緣由之一是: 在對Go語言不熟悉的前提下編寫的Go測試代碼超爛, 不徹底相同的測試環境. 具體表現有如下幾點:
-noboundscheck
), Go語言是開啓的最後我總結的經驗是: 不要把各類PK的結果當真, 要關注它的變化過程, 這個更有意思!