3 回答

TA貢獻1817條經驗 獲得超6個贊
6g和8g編譯器并不是特別優化,因此它們生成的代碼并不是特別快。
它們旨在快速運行自己并生成可以的代碼(有些優化)。gccgo
使用GCC的現有優化遍歷,并可能與C進行更有意義的比較,但是gccgo尚未完成功能。
基準數字幾乎完全與執行質量有關。它們與這種語言沒有太多關系,除非實現花費了運行時支持基準測試實際上不需要的語言功能。在大多數編譯語言中,理論上足夠聰明的編譯器可以剔除不需要的內容,但是您到了要演示的地方,因為很少有真正的語言用戶編寫不使用該功能的程序。 。將事情移開而不完全刪除它們(例如,在JIT編譯的Java中預測虛擬調用目標)開始變得棘手。
FWIW是我自己對Go進行的非?,嵥榈臏y試(基本上是整數加法循環),gccgo朝著介于Cgcc -O0
和gcc -O2
C范圍內的范圍的快端生成了代碼。Go并不是天生就很慢,但是編譯器還不能做所有事情。對于使用10分鐘的語言來說,這不足為奇。

TA貢獻1839條經驗 獲得超15個贊
在Go FAQ的下一版本中,應顯示類似以下內容。
表現
為什么Go在基準X上表現不佳?
Go的設計目標之一是接近可比程序的C性能,但在某些基準上卻表現不佳,包括在測試/基準測試中的一些基準。最慢的速度取決于在Go中沒有可比較性能的版本的庫。例如,數字位數取決于多精度數學程序包,而與Go語言不同,C語言版本使用GMP(用優化的匯編程序編寫)。依賴于正則表達式(例如regex-dna)的基準本質上是將Go的權宜之計regexp軟件包與成熟的,高度優化的正則表達式庫(如PCRE)進行比較。
基準測試是通過廣泛的調整贏得的,大多數基準的Go版本需要引起注意。如果您測量類似的C和Go程序(反向補碼就是一個例子),您會發現這兩種語言的原始性能比該套件所表明的要緊密得多。
盡管如此,仍有改進的空間。編譯器很好,但是可能會更好,許多庫需要大量的性能工作,并且垃圾收集器還不夠快(即使這樣做,請注意不要生成不必要的垃圾會產生巨大的影響)。
這是來自最近的郵件列表線程的有關計算機基準測試游戲的更多詳細信息。
gccgo中的垃圾收集和性能(1)
gccgo中的垃圾收集和性能(2)
重要的是要注意,計算機基準測試只是一個游戲。在性能評估和容量規劃方面有經驗的人員會仔細地匹配實際和實際的工作負載;他們不玩游戲。
- 3 回答
- 0 關注
- 381 瀏覽
添加回答
舉報