從2010年的計(jì)算機(jī)語言基準(zhǔn)游戲中我們可以看到：Go平均比C慢10倍Go比Java慢3倍！考慮到Go編譯器會(huì)生成用于執(zhí)行的本機(jī)代碼，這怎么可能？Go的編譯器不成熟？還是Go語言存在一些內(nèi)在問題？編輯：大多數(shù)答案否認(rèn)Go語言的內(nèi)在緩慢，聲稱問題出在不成熟的編譯器中。因此，我進(jìn)行了一些自己的測試來計(jì)算斐波那契數(shù)：迭代算法在Go（freebsd，6g）中以與sameC（帶有O3選項(xiàng)）一樣的速度運(yùn)行。遲鈍的遞歸代碼在Go中的運(yùn)行2 times速度比在C中運(yùn)行的慢（使用-O3選項(xiàng)；使用-O0-相同）。但是我還沒有看到基準(zhǔn)測試中出現(xiàn)10倍的下降。
3 回答
慕的地6264312
TA貢獻(xiàn)1817條經(jīng)驗(yàn) 獲得超6個(gè)贊
6g和8g編譯器并不是特別優(yōu)化，因此它們生成的代碼并不是特別快。
它們旨在快速運(yùn)行自己并生成可以的代碼（有些優(yōu)化）。gccgo使用GCC的現(xiàn)有優(yōu)化遍歷，并可能與C進(jìn)行更有意義的比較，但是gccgo尚未完成功能。
基準(zhǔn)數(shù)字幾乎完全與執(zhí)行質(zhì)量有關(guān)。它們與這種語言沒有太多關(guān)系，除非實(shí)現(xiàn)花費(fèi)了運(yùn)行時(shí)支持基準(zhǔn)測試實(shí)際上不需要的語言功能。在大多數(shù)編譯語言中，理論上足夠聰明的編譯器可以剔除不需要的內(nèi)容，但是您到了要演示的地方，因?yàn)楹苌儆姓嬲恼Z言用戶編寫不使用該功能的程序。 。將事情移開而不完全刪除它們（例如，在JIT編譯的Java中預(yù)測虛擬調(diào)用目標(biāo)）開始變得棘手。
FWIW是我自己對(duì)Go進(jìn)行的非?，嵥榈臏y試（基本上是整數(shù)加法循環(huán)），gccgo朝著介于Cgcc -O0和gcc -O2C范圍內(nèi)的范圍的快端生成了代碼。Go并不是天生就很慢，但是編譯器還不能做所有事情。對(duì)于使用10分鐘的語言來說，這不足為奇。
紫衣仙女
TA貢獻(xiàn)1839條經(jīng)驗(yàn) 獲得超15個(gè)贊
在Go FAQ的下一版本中，應(yīng)顯示類似以下內(nèi)容。
表現(xiàn)
為什么Go在基準(zhǔn)X上表現(xiàn)不佳？
Go的設(shè)計(jì)目標(biāo)之一是接近可比程序的C性能，但在某些基準(zhǔn)上卻表現(xiàn)不佳，包括在測試/基準(zhǔn)測試中的一些基準(zhǔn)。最慢的速度取決于在Go中沒有可比較性能的版本的庫。例如，數(shù)字位數(shù)取決于多精度數(shù)學(xué)程序包，而與Go語言不同，C語言版本使用GMP（用優(yōu)化的匯編程序編寫）。依賴于正則表達(dá)式（例如regex-dna）的基準(zhǔn)本質(zhì)上是將Go的權(quán)宜之計(jì)regexp軟件包與成熟的，高度優(yōu)化的正則表達(dá)式庫（如PCRE）進(jìn)行比較。
基準(zhǔn)測試是通過廣泛的調(diào)整贏得的，大多數(shù)基準(zhǔn)的Go版本需要引起注意。如果您測量類似的C和Go程序（反向補(bǔ)碼就是一個(gè)例子），您會(huì)發(fā)現(xiàn)這兩種語言的原始性能比該套件所表明的要緊密得多。
盡管如此，仍有改進(jìn)的空間。編譯器很好，但是可能會(huì)更好，許多庫需要大量的性能工作，并且垃圾收集器還不夠快（即使這樣做，請(qǐng)注意不要生成不必要的垃圾會(huì)產(chǎn)生巨大的影響）。
這是來自最近的郵件列表線程的有關(guān)計(jì)算機(jī)基準(zhǔn)測試游戲的更多詳細(xì)信息。
gccgo中的垃圾收集和性能（1）
gccgo中的垃圾收集和性能（2）
重要的是要注意，計(jì)算機(jī)基準(zhǔn)測試只是一個(gè)游戲。在性能評(píng)估和容量規(guī)劃方面有經(jīng)驗(yàn)的人員會(huì)仔細(xì)地匹配實(shí)際和實(shí)際的工作負(fù)載；他們不玩游戲。
- 3 回答
- 0 關(guān)注
- 382 瀏覽
添加回答
舉報(bào)
0/150
提交
取消