Go 英文原文：Go 1.1 performance improvements Part1

这是第一次在一系列的文章等分析Go 1.1中对功用的改进。

早先已有报道（这里，和这里），只须轻易的应用Go 1.1重新编译性一下你的代码，就能够提升30-40%的功用。在linux/amd64平台中，这已被广泛的基准测试所支持。在linux/386和linux/arm平台中，这个结果甚至越发优秀，但这是末倒置的。

gccgo的留心事项。这一系列（series）重点在于GC系列编译器对Go 1.1功用改进(5g，6g和8g)的贡献。gccgo从这些改进中间接受益，因为它共享相似的运转时（runtime）和标准库（tandard library），但不是这一基准测试系列（benchmarking series）的中心。

Go1.1在编译器，运转时和标准库上有非常多直接招致次序速度提升的特点改进，特别是:

• 代码生成优化。涵盖3个gc编译器，包括更好的寄存器分拨，减少不必要的间接加载，减少代码量
• 内联优化。包括部格外置函数调用的内联，处理接口转换时编译器生成的存根方法的内联。
• 减少栈应用。进而减轻栈大小的压力，更少***栈。
• 引入并行残余汇集器。汇集器仍然是标记-删除，可是残余汇集时代可以使用一切的CPU。
• 更精细的残余汇集。减少堆的大小，进而获得更低的GC延时
• 新的运转时调解器。在调解goroutine时做出更好的决策。
• 调解器和net包整合的更紧密。大幅减少包处理的延时并获得更高的吞吐。
• 部分运转时和标准库用汇编重写。使用特定的Mobile或加密指令的优势。

autobench引见

没有现实依据的不成复现的评测比任何任务都让我不满。由于这个系列要列出大量的数字，给出一些强有力的结论，对我而言，有需求供应一个渠道，巨匠可以在自己机械上验证我的结果。

为此，我已经建立了一个轻易的基于make的Tools，用于比较Go1.0和Go1.1在一系列综合基准测试中的功用。它可以运转在任何Go支持的任何平台上。当然该项目仍处于开发阶段，它已经发作了十分多有效的数据。这些数据存放在代码库中。你可以在GitHub找到这个项目：

https://github.com/davecheney/autobench

我要感谢那些从自己机械提交基准测试结果数据的Go社区的成员，这使得我对Go1.1的绝对功用做出明智的结论。

假设你对参与autobench感兴味，很快将有一个记录Go1.1功用的分支出世。

一张图胜过千言万语

为了更好的展示基准测试结果，AJ Starks 已经开发了一个好用的Tools。benchviz 可以将misc/benchcmp单调的基于文本的输出转换成漂亮的图表。你可以在AJ的博客上看到一切关于benchviz 的信息。

http://mindchunk.blogspot.com.au/2013/05/visualizing-go-benchmarks-with-benchviz.html

在传统的misc/benchcmpTools之后，对一切的改进，当运转时间的减少，或者吞吐的增加，以条状图的方法向右扩展，反之，向左收紧。

Go1 在linux/amd64平台基准测试

这篇文章的残剩部分将聚集中在linux/amd64的功用评测。6g编译器被认为是gc编译器包中的旗舰编译器。除在前后端的代码生成优化，标准库和运转时的功用敏感部分已经用汇编重写以充分使用SSE2指令。 

这篇文章接下来的数据来自尔后果文件 linux-amd64-d5666bad617d-vs-e570c2daeaca.txt

Go1基准测试包是一个综合的基准测试，它试图取得真实全国中标准库中的重要包的应用情况。全体上，这个结果支持之前30%-40%功用提升的结论。颠末check提交到autobench库中的结果，很清楚GobDecode和Gzip功用有所退步，并且问题 5165 和 5166 都发作了。绝对而言，后者的罪魁祸首该当起码部分归于迁移到64位int 。

net/http包基准测试

这一系列的基准测试是从net/http包中抽出来的，它展示了Brad Fitzpatrick 和Dmitry Vyukov和非常多其他人贡献到net和net/http包中的Task。

这个系列的基准测试中需求指出的是，ReadRequest（用于解包一个HTTP央求）的功用提升。ClientServerParallel基准测试目前实在不能在一切的amd64平台运转，因为部分amd64平台还不支持新的和net聚合的运转时。完成残剩的BSD和Windows平台的支持是 1.2周期的重点。

Runtime 微基准测试

在这里展示的最后一个基准测试是从runtime包中抽取的。

Runtime基准测试展示了runtime包非常低层次部分的微型基准测试。

上面清楚的衰退就是第一个Append基准测试。可是在理论时间中，基准测试却从36ns/op提升到100ns/op,这意味着，关于某些append应用场景是存在功用衰退的。这可能已经在建议CL 9360043中指出。

Runtime基准测试中最大的赢家就是惊人的map。新的map代码由khr在issue 3886声明并贡献。包括Channel操作的开支减少（感谢Dmitry的新调解器），触及complex128操作的优化，和用64位汇编重写的hash和内存Mobile操作的提速。

结论

关于（运转于）今世的（modern）Intel 64位CPU中的linux/amd64平台，6g编译器与运转时（runtime），分明带来更快的代码（运转速度）。其它amd64平台有类似的速度提升，当然具体的改进有所不合。我鼓舞你重新checkautobench知识库（repository）中的基准测试数据，并且假设有才干的话，提交你自已的结果。

在随后的文章中，我将会商Go 1.1对386和arm 平台带来的性能提升。

本文中的一切译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译Task依照 CC 协议，假设我们的Task有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,供给担保交易、源码交易、虚拟商品、在家创业、在线创业、Task交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接生意、网站交易、广告生意、站长培训、建站美工等服务