网站代码多彩,外卖小程序怎么制作,类似wordpress博客,全球十大电商平台排名文章目录 参考文章PGO是什么使用PGO的好处PGO做了什么热函数内联什么是内联内联的好处Go默认的内联策略查看内联预算PGO的热函数内联 去虚拟化调用指令高速缓存 PGO有什么缺点可执行程序变大构建时间变长 PGO怎么使用典型的工作流程收集CPU配置文件生产环境启动PGO代码改动重新… 文章目录 参考文章PGO是什么使用PGO的好处PGO做了什么热函数内联什么是内联内联的好处Go默认的内联策略查看内联预算PGO的热函数内联 去虚拟化调用指令高速缓存 PGO有什么缺点可执行程序变大构建时间变长 PGO怎么使用典型的工作流程收集CPU配置文件生产环境启动PGO代码改动重新生成CPU配置文件 PGO的未来个人看法QAQ1 PGO是否可以优化标准包和依赖的包Q2 CPU配置文件不当是否会使我的程序比没有 PGO 的速度慢Q3 怎么保证收集到公正的CPU配置文件Q4 不同运行环境下如何使用PGO 参考文章 PGO介绍https://andrewwphillips.github.io/blog/pgo.html生成profile配置文件https://andrewwphillips.github.io/blog/flame-graphs.html#generating-cpu-profiles 提案Go 的配置文件引导优化PGO的设计和实现https://go.googlesource.com/proposal//master/design/55022-pgo-implementation.md go官方文档使用PGO:https://go.dev/doc/pgo#:~:textCollecting%20representative%20profiles%20from%20production PGO为你的go程序提效5%https://colobu.com/2023/09/13/pgo/ PGO是什么 引入官方的说法https://go.dev/doc/pgo#merging-profiles从 Go 1.20 开始Go 编译器支持配置文件引导优化 (PGO) 以进一步优化构建。Profile-guided optimization (PGO)。配置文件引导优化 (PGO)也称为反馈导向优化 (FDO)是一种编译器优化技术它将应用程序的代表性运行中的信息配置文件反馈回编译器以供下一次构建应用程序使用。它使用该信息做出更明智的优化决策。例如编译器可能决定更积极地内联配置文件指示频繁调用的函数。在Go中编译器使用CPU pprof配置文件作为输入配置文件例如来自runtime/pprof或net/http/pprof。从 Go 1.22 开始一组代表性 Go 程序的基准测试表明使用 PGO 进行构建可将性能提高约 2-14%。 自Go 1.20版本引入PGO(profile-guided optimization)后PGO这种优化技术带来的优化效果就得到了持续的提升Go 1.20实测性能提升仅为1.05%Go 1.21版本发布时官方的数据是2%~7%而Go 1.21编译器自身在PGO优化过后编译速度提升约6%。在Go 1.22中官方给出的数字则是2%~14%这14%的提升想必是来自Google内部的某个实际案例。 使用PGO的好处 提升性能降低成本。在 Google 服务器上运行的大部分代码都是使用 PGO 构建的。当你考虑到我的估计所有这些服务器的电费每年必须接近如果不超过10 亿美元时PGO 每年可能至少为 Google 节省数千万美元。所以从经济上来说这是有道理的。 PGO做了什么 热函数内联 什么是内联 所谓内联指的是编译期间直接将调用函数的地方替换为函数的实现它可以减少函数调用的开销以提高程序的性能。 内联的好处 解除函数调用的开销以空间换时间支持编译器更有效地应用其他优化策略。 Go默认的内联策略 函数足够简单当解析AST时Go申请了80个节点作为内联的预算。每个节点都会消耗一个预算。函数的开销不能超过这个预算不能包含闭包deferrecoverselect不能以 go:noinline 或 go:unitptrescapes 开头必须有函数体其他等复杂要求详细可见src/cmd/compile/internal/gc/inl.go相关内容。我们可以使用 gcflags 参数来判断能不能内联。 查看内联预算 关于内联的预算可以使用编译命令-gcflags-m2查看详细的优化决策例如 可以看到哪个函数内联了哪个没有内联以及内联的成本。 go build -gcflags-m2 inl.go #/inl.go:3:6: can inline small with cost 7 as: func() string { s : hello, world!; return s } ./inl.go:8:6: cannot inline large: function too complex: cost 82 exceeds budget 80 ./inl.go:38:6: can inline main with cost 68 as: func() { small(); large() } ./inl.go:39:7: inlining call to small func() string { s : hello, world!; return s }当使用-gcflags-m2这个命令时会指示Go编译器输出更详尽的优化决策信息。这个-m标志被用来控制编译器的内联和逃逸分析信息的输出。在这个上下文中-m后跟等号和一个数字表示详细级别。 ● -m显示出哪些函数被内联。 ● -m2或者更高的数字如-m3会显示更多的信息包括为什么某些函数没有被内联比如说函数过于复杂以及变量逃逸分析的结果比如说哪些变量被移动到了堆上。 PGO的热函数内联 如果调用次数较多的函数所谓的热函数稍微超出内联预算则可能不会内联它们。PGO 做了几件事来使内联更加有效。首先它增加了热点函数的内联预算。PGO 避免内联 CPU 配置文件显示为冷函数的函数。同样这减少了不必要的代码膨胀。 去虚拟化调用 通过接口调用方法比直接方法/函数调用慢。CPU配置文件可以显示调用的具体类型是什么从而在编译的时候直接优化为具体类型的调用 type I interface { f() } ...var i I...i.f()# PGO优化# 热路径if a, ok : i.(A); ok {a.f() // direct call} else {i.f()}指令高速缓存 CPU 配置文件允许编译器通过代码查找常用执行路径或热路径。编译器将对函数内的代码块重新排序并且稍后在构建过程中链接器将调整函数的位置从而确定将它们加载到指令内存中的位置。 PGO有什么缺点 可执行程序变大 由于额外的函数内联PGO 可能会产生稍大的二进制文件。 构建时间变长 启用 PGO 构建可能会导致包构建时间显着增加。其中最值得注意的部分是 PGO 配置文件适用于二进制文件中的所有包这意味着首次使用配置文件需要重建依赖关系图中的每个包。这些构建像其他构建一样被缓存因此使用相同配置文件的后续增量构建不需要完全重建。例如https://github.com/golang/go/issues/58102 构建时间可能会增加好几倍当然go官方团队也在致力于解决这个问题。 PGO怎么使用 典型的工作流程 构建并发布初始二进制文件不含 PGO。从生产中收集配置文件。当需要发布更新的二进制文件时从最新源构建并提供生产配置文件。转到2 收集CPU配置文件 明确不开启PGO的情况下例如go build -pgooff使用pprof进行CPU配置收集收集结果为default.pgo。建议是收集生产环境的CPU配置文件更为精准当然如果可以保证测试/仿真环境和生产环境一致的话在测试/仿真环境收集也是OK的。 生产环境启动PGO go1.21之后默认开启了PGO,也可以在编译的时候手动设置。例如: 开启PGO: go build -pgoauto设置PGO配置文件路径 go build -pgo/tmp/foo.pprof 代码改动重新生成CPU配置文件 如果无法评估迭代对于CPU配置文件的影响建议是发布的时候重新收集CPU配置参考上面的流程。 go官方建议PGO文件可以提交到版本库里面方便对比和管理。 PGO的未来 有很多“微观”优化的机会。例如如果在堆上分配的变量不需要在热路径中转义则该变量可以在堆栈上分配并且仅在采用冷路径时才移动到堆。一件重要的事情随着泛型的使用越来越多是称为模板的功能。当在热路径中调用泛型函数时PGO 可以确定类型参数并专门为该类型生成代码甚至可能在热调用站点内联它未来要迭代的方向https://github.com/golang/go/issues/62463 个人看法 对于GO程序来说大家认为整体还是比较高效的只是相对于c和rust来说性能确实有差距可能达到25%的性能差距但是GO的易用性和生态弥补了这一缺陷。只是谁又不想让自己的程序快一点占用资源少一点呢 对小型项目来说关注新技术即可没必要强行上PGO。毕竟有一定的构建成本且小型项目对性能和成本不敏感。而对于大型项目或者大型互联网公司来说例如字节B站这些别说14%的优化了2%的优化都值得正确可能带来的是千万级的成本节省。 QA Q1 PGO是否可以优化标准包和依赖的包 是的。 Go中的PGO适用于整个程序。所有包都会重新构建以考虑潜在的配置文件引导优化包括依赖项中的包。这意味着应用程序使用依赖项的独特方式会影响应用于该依赖项的优化。 Q2 CPU配置文件不当是否会使我的程序比没有 PGO 的速度慢 不应该。虽然不代表生产行为的配置文件将导致应用程序冷部分的优化但它不应该使应用程序热部分变慢。如果您遇到 PGO 导致性能比禁用 PGO 更差的程序请在go.dev/issue/new提交问题。 Q3 怎么保证收集到公正的CPU配置文件 在高峰期平稳期或者任何时间都可以收集CPU配置文件合并收集到的多个配置文件 $ go tool pprof -proto a.pprof b.pprof merged.pprof这种合并实际上是输入中样本的简单求和无论配置文件的墙持续时间如何。因此当分析应用程序的小时间片例如无限期运行的服务器时您可能希望确保所有配置文件具有相同的墙持续时间即收集所有配置文件 30 秒。否则具有较长墙持续时间的配置文件将在合并的配置文件中过多表示。 Q4 不同运行环境下如何使用PGO 相同的CPU配置文件可以在linux和windows上的应用程序使用。对于大多数应用程序来说绝大多数代码是平台无关的因此这种形式的退化是有限的。为不同运行环境生成独有的CPU配置。代价就是增加管理负担。 end