我一直在試驗(yàn) gc 和 gccgo，我遇到了一些奇怪的行為。使用我曾經(jīng)編寫的程序來測試一些定理，我得到了以下結(jié)果：（為了可讀性，我刪除了不必要的信息）$ time go build -compiler gc -o checkprog_gc checkprog.go (x 3)go build <...> 0.13s user 0.02s system 100% cpu 0.149 totalgo build <...> 0.13s user 0.01s system 99% cpu 0.148 totalgo build <...> 0.14s user 0.03s system 100% cpu 0.162 total --> average: 0.13s user 0.02s system 100% cpu 0.153 total$ time go build -compiler gccgo -o checkprog_gccgo checkprog.go (x 3)go build <...> 0.10s user 0.03s system 96% cpu 0.135 totalgo build <...> 0.12s user 0.01s system 96% cpu 0.131 totalgo build <...> 0.10s user 0.01s system 92% cpu 0.123 total --> average: 0.11s user 0.02s system 95% cpu 0.130 total$ strip -s -o checkprog_gc_stripped checkprog_gc$ strip -s -o checkprog_gccgo_stripped checkprog_gccgo$ ls -l 1834504 checkprog_gc* 1336992 checkprog_gc_stripped* 35072 checkprog_gccgo* 24192 checkprog_gccgo_stripped*$ time ./checkprog_gc./checkprog_gc 6.68s user 0.01s system 100% cpu 6.674 total./checkprog_gc 6.75s user 0.01s system 100% cpu 6.741 total./checkprog_gc 6.66s user 0.00s system 100% cpu 6.643 total --> average: 6.70s user 0.01s system 100% cpu 6.686 total$ time ./checkprog_gccgo./checkprog_gccgo 10.95s user 0.02s system 100% cpu 10.949 total./checkprog_gccgo 10.98s user 0.01s system 100% cpu 10.964 total./checkprog_gccgo 10.94s user 0.01s system 100% cpu 10.929 total --> average 10.96s user 0.01s system 100% cpu 10.947 total我可以看到以下模式：用它構(gòu)建的二進(jìn)制文件的gccgo大小要小得多（剝離無助于改變這種差異）使用構(gòu)建的二進(jìn)制文件gc執(zhí)行速度更快構(gòu)建gccgo比使用多一點(diǎn)時(shí)間gc我還測試了其他一些 go 程序（雖然不是那么廣泛），但它們都表現(xiàn)出相同的行為。這似乎與這個(gè)答案所說的相矛盾：簡而言之：gccgo：更多優(yōu)化，更多處理器。我認(rèn)為更多的優(yōu)化意味著更快的二進(jìn)制文件，同時(shí)需要更多的時(shí)間來編譯......這三種模式的原因是什么？
2 回答
三國紛爭
TA貢獻(xiàn)1804條經(jīng)驗(yàn) 獲得超7個(gè)贊
有很多不同之處——布拉菲茨在 2014 年 5 月的一次談話中談到了其中的一些：
gccgo可以生成一個(gè)動(dòng)態(tài)鏈接的二進(jìn)制文件libgo，這使得輸出更小，但意味著要在目標(biāo)機(jī)器上安裝相關(guān)庫。cgo沒有這個(gè)要求的二進(jìn)制文件。gccgo進(jìn)行更多的低級(jí)優(yōu)化，因?yàn)樗梢允褂?code>gcc的代碼生成器和優(yōu)化器。編寫一些數(shù)據(jù)壓縮代碼，gccgo 的運(yùn)行速度明顯快于gc. 這些相同的優(yōu)化使編譯器變慢：它正在做更多的工作。gccgo支持目標(biāo)處理器gcc，因此它是進(jìn)入某些架構(gòu)（如 SPARC、ARMv8（64 位）或 POWER）的唯一途徑。（Canonical 使用它為 arm64 和 ppc64 編譯他們的 Juju 服務(wù)編排工具。）gccgo并且gc兩者都支持 ARMv7（32 位），但是根據(jù) bradfitz 的說法gc并不能生成最高效的 ARM 代碼。有某些優(yōu)化只有
gc。一個(gè)重要的問題是轉(zhuǎn)義分析，其中編譯器確定某些變量永遠(yuǎn)不會(huì)“轉(zhuǎn)義”分配它們的函數(shù)，因此可以進(jìn)行堆棧分配。（因此，令人驚訝的是，
new(T)如果其返回值沒有轉(zhuǎn)義，則可能不會(huì)進(jìn)行堆分配。）這減少了垃圾收集需要運(yùn)行的頻率。另一個(gè)是
.s標(biāo)準(zhǔn)庫中的匯編程序文件僅通過 鏈接gc，因此gccgo默認(rèn)情況下不使用諸如英特爾硬件 CRC32C 之類的東西（您必須專門為 gccgo 提供實(shí)現(xiàn)）。gc首先實(shí)現(xiàn)新的語言功能，并且通常比最新的gccgo.
皈依舞
TA貢獻(xiàn)1851條經(jīng)驗(yàn) 獲得超3個(gè)贊
大小不同，因?yàn)?gc 生成靜態(tài)二進(jìn)制文件，而 gccgo 鏈接到 libgo。這意味著整個(gè)運(yùn)行時(shí)（調(diào)度程序、垃圾收集器、映射、通道）的代碼不在 gccgo 創(chuàng)建的最終二進(jìn)制文件中。
編譯速度當(dāng)然有利于gc。GC 的構(gòu)建考慮了編譯速度。它還通常會(huì)生成較少優(yōu)化的代碼，并且需要執(zhí)行的工作較少。
現(xiàn)在討論為什么 gc 仍然更快。事實(shí)是，它們中的任何一個(gè)都不總是比另一個(gè)快。例如，嘗試 md5 一個(gè)文件，GCCGO 會(huì)快一個(gè)數(shù)量級(jí)。嘗試用很多通道來實(shí)現(xiàn)一些東西，gc 肯定會(huì)贏。你不能總是提前知道哪個(gè)會(huì)成功。GC 往往具有更高效的并發(fā)性，而 gccgo 往往更擅長數(shù)學(xué)。但是，這是您需要根據(jù)具體情況進(jìn)行測試的。最好使用 go test 的基準(zhǔn)測試系統(tǒng)而不是時(shí)間。
- 2 回答
- 0 關(guān)注
- 230 瀏覽
添加回答
舉報(bào)
0/150
提交
取消