Go 1.1 的性能提升——第二篇
by Codefor
at 2013-05-26 01:15:44
original http://blog.jobbole.com/40164/?utm_source=rss&utm_medium=rss&utm_campaign=go-1-1-%25e7%259a%2584%25e6%2580%25a7%25e8%2583%25bd%25e6%258f%2590%25e5%258d%2587-%25e7%25ac%25ac%25e4%25ba%258c%25e7%25af%2587
这是探讨最近发布的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操作。结果不言自明。
benchmark old MB/s new MB/s speedup BenchmarkCompareStringBigUnaligned 29.08 1145.48 39.39x BenchmarkCompareStringBig 29.09 1253.48 43.09x
结论
虽然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/
【非特殊说明，转载必须在正文中标注并保留原文链接、译文链接和译者等信息，谢谢合作！】