Go 1.1 的效能提升——第二篇

這是探討最近釋出的Go1.1效能提升三篇系列文章中的第二篇。

在第一篇中，我們探討了amd64平臺上的效能提升，以及所有平臺受益於執行時和編譯器前端效能優化得到的普遍效能提升。

這篇文章中，我將主要著重於執行在386機器上Go1.1的效能。文章中的評測結果源自linux-386-d5666bad617d-vs-e570c2daeaca.txt。

 

Go1 在linux/386平臺的基準測試

談到效能，8g編譯器是個短板。386開發模型中，可用的通用暫存器數目較少，及其詭異使用限制對編譯和優化帶來了很大挑戰。然而，這阻擋不了Rémy Oudompheng在Go1.1開發過程中對8g編譯器作出許多重大貢獻。

首先，古怪的387浮點數模型被棄用（除非你執行在非常古老的帶有GO386=387開關的硬體上），並由SSE2指令取代。

其次，Rémy做了很多努力，從6g遷移了程式碼生成優化的程式碼到8g（同時也遷移到了5g，arm編譯器）。涉及遷移的程式碼包括編譯器前端、垃圾收集，以及引入了一個將除法重寫為簡單的移位和乘法操作的框架

整體上看，這臺機器上的linux/386結果顯示出了和linux/amd64一樣的效能提升，甚至某些基準測試項還超過了後者。然而，和linux/amd64不一樣的是，Gzip和Gob基準測試中，linux/386效能沒有衰退。

BinaryTree17 和 Fannkuch11這兩個測試項輕微地效能衰退，應該是由因為垃圾收集器變得更加精確引起的。垃圾收集器更加精確，引入了一些額外的記賬資訊來記錄分配在堆上的物件的大小和型別，進而反映在以上基準測試中。

 

net/http 基準測試

之前一篇linux/amd64文章中展示出來的net包中的效能提升在linux/386平臺一樣存在。ClientServer基準測試的效能提升並沒有像amd64那樣被標出來，然而，由於執行時和net包結合的更加緊密，整體上仍然表現出顯著的效能改善。

Runtime 微基準測試

和第一篇的amd64基準測試一樣，runtime微基準測試顯示出了有好有壞的結果。一些低層次的操作變的稍微慢一些，同時，其他一些操作，如map，效能有顯著提升。

最後這兩個基準測試，截斷在下面，是因為他們效能提升太多了，螢幕容不下。這個效能提升主要歸功於這個變化，其為strings，bytes，runtime包引入了一個更快的低層次的Equals操作。結果不言自明。

 

結論

雖然8g不是gc系列編譯器中的最好的，（Ken Thompson自己也曾說，386平臺基本上沒有多餘可用的暫存器），linux/386很容易就實現了之前聲稱的30%-40%的效能提升。甚至在一些基準測試中，相比Go1.0，linux/386打敗了linux/amd64

除此之外，由於記憶體使用的減少，現在所有的編譯器在編譯時只需要大概之前一半的記憶體，這樣的直接結果就是Go1.1比Go1.0編譯速度提高了30%。 我鼓勵你去審查autobench程式碼庫中的基準測試資料。如果你有能力，請提交你自己的測試結果。

在這個系列的最後一篇文章中我將關注Go1.1給arm平臺帶來的效能提升。我向你保證，最後一篇的將是最精彩的。

 

 

英文原文：Dave Cheney，感謝@Codefor 的熱心翻譯。如果其他朋友也有不錯的原創或譯文，可以嘗試推薦給伯樂線上。

譯文連結：http://blog.jobbole.com/40164/

【非特殊說明，轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】