BOLT 二进制反馈优化技术

本文涉及的产品
云服务器 ECS,u1 2核4GB 3个月
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
简介: 大型应用的代码往往达到数十甚至上百MB,这导致在程序执行时缓存机制无法充分利用,导致大量时间花费在CPU和内存链路上。通过对热点函数的布局进行优化,我们可以更好地利用CPU cache,从而获得较为可观的性能提升。针对这一问题,在编译技术上有PGO和Bolt两种解决办法,两者都是一种通过收集程序在运行时如跳转,调用关系,函数热度等执行信息,这些收集到的程序运行情况数据(profile data),可以更好地指导一些程序优化的策略,如是否对函数进行内联,以及对基本块和函数布局的排布来提高特定场景下的程序性能。

BOLT 二进制反馈优化技术

大型应用的代码往往达到数十甚至上百MB,这导致在程序执行时缓存机制无法充分利用,导致大量时间花费在CPU和内存链路上。通过对热点函数的布局进行优化,我们可以更好地利用CPU cache,从而获得较为可观的性能提升。针对这一问题,在编译技术上有PGO和Bolt两种解决办法,两者都是一种通过收集程序在运行时如跳转,调用关系,函数热度等执行信息,这些收集到的程序运行情况数据(profile data),可以更好地指导一些程序优化的策略,如是否对函数进行内联,以及对基本块和函数布局的排布来提高特定场景下的程序性能。

BOLT 的特点

PGO和Bolt两种方式都是基于收集到程序运行数据进行优化,但存在一定差异。不同于PGO通过编译器进行再次编译,Bolt是一个二进制优化和布局工具,直接对可执行文件/动态库ELF文件进行解析和进行修改,无需再次通过编译器进行构建。

image

image

在业务落地和优化结果方面,Bolt和PGO主要有以下两个方面的区别。

  1. Bolt在函数和基本块布局上能拿到更好的效果

编译器对函数的布局通常都是在编译优化的最后一步。在使用PGO的过程中,一个无法避免的问题就是函数内联等优化会导致上下文发生变化进而收集数据不准确,尤其是基本块排布需要的分支概率。而Bolt避免了callsite等信息的改动,专注于函数和函数内部的排布进行优化,可以得到更好的效果。

因此,Bolt和PGO在编译优化方法中并不是互斥的,是可以相互弥补的。在实践中,我们发现PGO和Bolt的优化在很多场景下是可以串联的,同时使用可以获得更好的性能收益。

image

  1. Bolt在有大型项目的部署会更加友好

这里的部署友好主要体现在三个方面,1) 更容易被集成到应用的构建系统中。Bolt在构建脚本中无需重复编译器的编译流程,这对于很多构建方式复杂的应用方来说构建修改更加友好,更方便落地。2)更快地构建速度。无需重复编译器流程也以为者通过Bolt进行优化能拿到比PGO更快的构建速度,比如编译器构建一次要20-30分钟的Clang使用Bolt只需要20~30秒。这对于单次编译就长达数小时的应用来说显然更容易接受。 3)Bolt可以对第三方的静态库进行优化。大型应用中往往很多第三方库的依赖,Bolt的好处之一就是可以其可以对静态链接进来的第三方库进行优化,而PGO则需要对第三方库逐个重新构建,在直接依赖于第三方静态库的场景中无法使用。

BOLT 在 Arm 当前现状

由于Bolt社区中,Arm后端当前只可以通过非LBR形式的运行时数据,数据无法记录函数调用关系和条件跳转指令上跳转发生的比率,因此Bolt后的结果相较X86差距较大

而通过coresight采样的数据有更精准的信息,我们能在倚天上获得同X86/LBR相同的精度,如跳转指令的起始和终止位置,以及函数间的调用。因此使用coresight采集出的数据能匹配到源代码中函数内的跳转发生方向和函数间的调用关系,对代码段进行重新布局提高热代码密度,降低I-cache/I-TLB miss进而优化程序性能表现。而非coresight的perf采样仅能获得函数及采样时pc相对于函数的偏移,无法满足反馈优化所需的信息。

image

其次,由于Arm后端尚不支持插桩的方式,当使用coresight数据时仍有不少bug,存在一定风险。 Alibaba Cloud Compiler对Bolt进行了集成,针对Arm和X86后端进行修复和优化,并在倚天上完成了多个项目的POC,目前在倚天上测试效果较Bolt on X86总体上有更好的性能提高。

image

目录
相关文章
|
1月前
|
数据采集 编解码 数据处理
LabVIEW并行模拟和数字数据流的获取和分析 人类脑电波和决策行为
LabVIEW并行模拟和数字数据流的获取和分析 人类脑电波和决策行为
21 0
|
1月前
|
存储 算法 数据挖掘
R语言和Python用泊松过程扩展:霍克斯过程Hawkes Processes分析比特币交易数据订单到达自激过程时间序列
R语言和Python用泊松过程扩展:霍克斯过程Hawkes Processes分析比特币交易数据订单到达自激过程时间序列
|
1月前
|
消息中间件 存储 监控
深入剖析:Kafka流数据处理引擎的核心面试问题解析75问(5.7万字参考答案)
Kafka 是一款开源的分布式流处理平台,被广泛应用于构建实时数据管道、日志聚合、事件驱动的架构等场景。本文将深入探究 Kafka 的基本原理、特点以及其在实际应用中的价值和作用。 Kafka 的基本原理是建立在发布-订阅模式之上的。生产者将消息发布到主题(Topic)中,而消费者则可以订阅这些主题并处理其中的消息。Kafka包括多个关键组件,如生产者、消费者、主题分区、ZooKeeper 等,Kafka 实现了高性能的消息传递和存储。特点:高吞吐量、可持久化存储、水平扩展、容错性和实时性等。
138 0
|
7月前
|
JSON 监控 安全
处理大规模数据流:使用Java编写公司聊天监控软件的数据处理模块
在今天的数字时代,企业越来越依赖聊天公司监控软件来确保员工的上网安全、保护敏感信息,并监测内部通信。为了更有效地处理和分析这些大规模数据流,公司通常需要自定义的数据处理模块。在本文中,我们将探讨如何使用Java编写这样的模块,同时确保跨平台部署。
180 0
|
存储 算法 JavaScript
Tubes响应性数据系统的设计与原理
本文详细介绍了响应性数据系统在 Tubes 中的运用,以及响应性数据系统的三种不同设计与原理。 Tubes是一套面向C端搭建场景,支持灵活扩展、极致性能和高稳定性的终端渲染解决方案,目前广泛运用在淘宝、天猫,包括:双11、618会场、淘宝新人版首页等业务场景。
530 0
Tubes响应性数据系统的设计与原理
|
消息中间件 分布式计算 Kafka
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证1
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证1
258 0
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证1
|
消息中间件 存储 缓存
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证2
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证2
395 0
【Flink】(九)状态一致性、端到端的精确一次(ecactly-once)保证2
|
消息中间件 存储 Kafka
宏观解释Kafka数据发送流程
宏观解释Kafka数据发送流程
184 0
宏观解释Kafka数据发送流程
|
Web App开发
浅析WebRtc中视频数据的收集和发送流程
本文是基于PineAppRtc开源项目github.com/thfhongfeng… 因为一个需求,我们需要将一个视频流通过WebRtc发送出去,所以就研究一下WebRtc是如何采集视频数据并进行处理发送的,于是有了这篇文章。
404 0
|
机器学习/深度学习 编解码 5G
前传感知的协作传输和接收之上行链路 | 带你读《5G系统关键技术详解》之十二
本节说明了上行链路和下行链路 C-RAN 的波束成形 设计技术,并将 C-RAN 用户的理论可实现速率表征为前传容量限制的函数。
前传感知的协作传输和接收之上行链路   | 带你读《5G系统关键技术详解》之十二