牛人自述，我是华为编译器的优化师

我是“翻译官”优化师--吴锋

2015年我加入华为中软院编译器实验室，那时候它还叫欧拉六部。

 

其实程序员敲代码写的编程语言机器是看不懂的，需要先翻译成汇编语言，也就是一条条指令，再转换成二进制，这样机器才明白我们要做什么。编译器就像是“翻译官”，把程序员懂的编程语言转化成机器认识的二进制，如果这个“翻译官”看不懂编程语言或者翻译的速度慢，在性能上的影响就可想而知了。

 

性能虽然可以通过手动改写汇编语言（机器指令）进行优化，但汇编语言复杂难写、工作量大、不易理解，如果不想写汇编却要有接近汇编的性能，就得依赖于一款强大的编译器，这就是我们做编译器的目标和使命。

 

 

 

从使用者到开发者

 

刚来华为的半年比较痛苦，技术讨论的时候周围的同事都是资深研发，说起技术来头头是道，我经常听得云里雾里，搞的我每次开会心理压力都很大。

 

编译器这个东西门槛高，技术深。为了对这一块有更深的理解，尽快上手，我记得当时是早上8点上班，我一般提前一小时7点到工位，结合实际的应用，带着问题看代码，我把编译器里面一些常用模块的代码看了不知道多少遍。

 

因为在上一家公司近7年嵌入式领域的积累，我对性能（时延）比较敏感，渐渐地我也发现了自己擅长从用户角度出发，提出产品的问题和优化点。从此我在华为所做的诸多大事小事，也基本离不开“优化”两字。

 

很快我就迎来了自己的第一次出差，是去上海。一天主管过来说：“有个项目提了紧急援助，你们去攻关一下”。虽然这活一听，就比较难搞定，但是对于还没有转正的我来说是一个很好的机会，于是我做好了摩拳擦掌、大显身手的准备。在那之前，我只知道华为人为了业务是敢打敢拼，还没有真正见识过，直到我参与了这次项目，第一次感受到为了冲刺交付的那股热血。我到现在都记得，那段时间是冬天，很冷，但我在上研所“与世隔绝”，每天早上进去，晚上出来，仿佛外面雨雪风霜都与我们无关。

 

当时正值无线5G技术的大PK，各大厂商搞得如火如荼。无线同事们攻关数月，已经取得很大进展，但是在基带业务上遇到性能瓶颈，业务处理时延值远大于目标值。经过分析讨论，分解给我们编译器的任务是优化十几个算法处理类函数，当前指标相比预期，有的甚至差距十几倍乃至几十倍。受到周围热血攻关的气氛的影响，我拿到任务也是一头扎进去，基于之前多年的经验以及前段时间的苦学，面对第一个需要优化的函数，我从拿手的汇编开始分析，很快便发现了性能差的主要原因。因为对编译器性能的了解，略微调整下算法中C语言某一段代码的写法，竟然就成功了，函数性能一下子提升X倍，达成了预期目标！这个结果令我兴奋不已，这一定程度验证了我之前努力的成效，更是给了我莫大的鼓励，让我对接下来的挑战充满信心。

 

最后经过两周的攻关，我们达成了全部的目标，帮助产品解决了当前项目中的最大阻塞点。这次给我最深的感悟就是优化不是靠“磨”出来的，解决第一个的时候还在摸索，到后面慢慢就掌握了一些方法门路，越来越上手了。

 

数着cycle过日子的“火锅小分队”

如果说第一次攻关我们是援军，那么第二次攻关我们就是主力军，而我更是主力军中的先锋。

 

那会儿无线准备开发第一代自研矢量核，相比于普通核，芯片支持更宽的矢量计算，因此在矢量化后可以将运算次数缩减到1/X，让芯片的性能提升X倍，我们团队承接了其配套的编译器开发，把实现矢量化功能的代码“翻译”给芯片。

 

业务对我们的要求非常高，我们第一次出来的版本在业务侧验证，性能仅有手写汇编的30%，距离既定目标差的非常远。在现场直面产品的我很受打击。身体僵坐在工位上看着屏幕上的代码，听着业务侧的同事拍桌子质问：“这么大的差距，怎么追？”没有人能比我当时的心情更着急。接下来，我们和产品矢量核业务开发团队开展联合优化，一方面双方可以一起探索如何写出高性能的矢量核代码；另一方面，在探索过程中，我们可以了解业务特点，发掘编译器的待改进点。他们做功能，我们优化性能，双管齐下。

 

各个模块里业务侧都有自己的期望值，一开始的差距甚至都在2倍3倍以上。经过我们和业务侧的讨论，不久就确定了各个项目里程碑计划表。面对巨大的gap，没有时间给我浪费，而且越到后面优化难度越大。

 

编译器的性能优化目标都是参考极致手写汇编来确定的通常我们用cycle（机器执行指令频率）数作为衡量性能的指标。Cycle的数量越少，说明耗时越短，性能越优。在那段时间里，我的脑子里面全是cycle，今天优化了多少cycle，我们距离下一个里程碑还有多少cycle，在接下来的日子里需要每天保持优化多少cycle。夜晚别人是数着绵羊入睡，我大概是念叨着cycle入睡……虽然偶尔会有些焦虑，但只要我做到今日cycle今日毕，就是在朝着目标一步步前进！

 

还记得被cycle支配的漫长异地攻关期，上研食堂的小火锅是我们的最爱，又快又方便。一次在距离里程碑期限快要到了的时候，还有许多cycle没有优化完成。我和另外两个同事嘴里吃着丸子，心里默默念叨着自己的cycle。到最后有个同事越吃越没劲，只想赶快回到工位工作，这时候锅里还剩了好几个丸子。我就拉着他说：“你吃完，别浪费，你吃一个丸子我给你减少100个cycle怎么样?”他扑哧一下笑出声。其实，我也明白兄弟们压力都很大，虽然很艰难，希望大家能有时间放松一下紧绷的弦……

 

在持续攻关了三个多月后，我们终于看到了曙光。一方面业务侧性能已经基本达到预期，双方已联合摸索出一套适配当前芯片架构的代码写法，另一方面编译器引入和增强了许多的算法，各个模块都已达成了90%手写汇编的既定目标，在一些典型业务上的性能结果逼近汇编。而我心里的大石头终于放下了，我想自己再也不用每天数着cycle过日子了，这场仗，我们打赢了！

 

项目结束后，我们几个兄弟大快朵颐地吃了顿火锅，还点了不少小丸子，大家聊起攻关岁月，都觉得那场景恍如隔日，却又记忆犹新……

 

“不能在我这掉链子”

 

这个项目结束不久后，我就成为了团队的SE。对于普通开发而言，工作偏向于聚焦某一个问题；而作为SE，团队的对外技术发言人，需要花更多的精力去分析项目中的技术风险，并探索新技术，需要背负整个项目的压力。

 

由于编译器在第一代核上的性能达到了汇编的90%，在之后一代代的芯片演进过程中，90%的指标自然就成为了业务侧对我们编译器特性的最低要求。然而特性越来越复杂，技术难度更像是一道难以跨越的鸿沟，我们的标准却并没有降低。

 

记得在某一代矢量核演进过程中引入了一个新特性，该特性是当代芯片架构演进的主要提升点，但是这个特性在业界没有任何先例技术。开会的时候，设计的同事斩钉截铁地说着：“做不到90%，就不能达标”。

 

当时听到这话的我，瞬间压力巨大。由于该特性的编译器实现没有业界可参考经验，我们就是从零开始，需要完全自研的设计开发。关于这个技术的特点，编译器现有的能力，将来这块能不能做？能做到什么程度？这些都是我要考虑的风险点。我不敢轻易承诺，但有时候我又不得不承诺。

 

在这种承诺下，我只能自己消化。当务之急就是对这个最大的风险特性做一个能力评估，时间紧迫，平时开发一个新特性都要2-3个月，但那时的我没有时间了。我花了2天时间通读了该特性的所有描述，并理解每一个细节；同时还调研了业务场景，梳理哪些场景我们可以支持，哪些将会是风险，最后在两周内给出commit（确认）。

 

之后，我又花了几天时间实现了一个demo，进一步证实了我们的基本方案的可行性。基于方案初稿，我们评估可以覆盖80%的业务场景，剩下的20%也可以通过一些定制化扩充来进一步支持。至此，我们可以commit 90%的目标，虽然仍有风险，但已经有了底气。

 

那段时间，我经常在会后一个人默默复盘，思考着会议上大家提出的问题技术上是否可以通过外部交流帮助；编译器到底需要解决哪些问题，才能风险可控，将来又怎么去弥补。毕竟我要对项目负责，对团队负责。要知道到目前为止，我们团队可是从来没有过“败绩”，我们之前没有一次掉链子的，更不能在我这掉链子，我做出的承诺就要达到。当然最终我们也是顺利达成了目标。

 

与可信风险说“不”

 

2018年下半年，公司开始推行软件工程能力提升项目，很多团队都大刀阔斧地进行了可信改革，我们的编译器优选版本定了5年更新一次的计划。

 

编译器在CT领域进行了近10年的交付，特别是在无线场景，支撑的芯片类型非常多，每种芯片类型编译器支撑的版本也不尽相同，所以整个编译器的“可信”工程是艰巨的，存在可信风险，亟需升级。另一方面我们是自研芯片的编译器，在获得高性能的同时还有很多的业务协同优化，牵一发动全身，一旦编译器发生变更，涉及协同优化部分的代码调整将会是最痛苦的煎熬。此外，自研芯片已经演进了那么多代，升级后每一代都要重新配套。而我们半年后将迎来客户交付时间点，要在那之前完成6款自研编译器的升级，时间上也将是一个巨大的风险。

 

面临这么多困难当前，我们编译器难道不升级了？

 

不，作为负责无线领域的编译器SE，我要带领团队与时间赛跑，我们交付的编译器不仅要高性能，还要高可信。我一直认为，作为SE，可信设计其实就是本职工作，并不是今天公司搞可信，我们才扑上去搞，而应该是在平时的设计开发中，就要去考虑的。虽然版本升级时间紧、任务重，但我还是给这次任务增加了额外的难度，既然未来是要继续升级，考虑到后续代码的可维护性，索性这次就直接从系统层面做一个大重构，一步到位！

 

说实话，这么重要又有难度的挑战，我心里也打鼓，毕竟这不仅是编译器团队的事，还牵扯着协同业务的优化，更重要的是不能影响后续客户的交付节奏和质量，我们不容有失。

 

半年的时间痛苦又漫长，通过多次攻关联调，经过了很多个重构，我们终于完成了全部的自研芯片编译器版本升级。不仅保障了升级后的各个编译器在业务侧性能没有下降，消除了芯片应用上的可信风险；同时我们在升级过程中，也做了很多的架构解耦工作，包括开源与自研代码解耦，多个芯片之间的接口抽象等，以利于下次升级。给客户、也给我们自己交了一份满意的答卷。如今再回首，我觉得一切都是最值得的，对于可信的风险，我们必须迎难而上！

 

 

 

最后，我想说，我们团队是一支历史悠久的团队，伴随着无线自研芯片一路成长，未来软件优化更显重要，编译器在其中的重要性不言而喻。SE是团队的领航者，不仅要保证当前项目的成功，还要为团队的未来发展找技术方向。高性能、高可信不仅仅只是口号，而是需要我们去持续打造

相关文章推荐：

华为24年，49岁，他一直在编码

一个博士应聘华为，大疆的经历...

华为员工裸辞之后悟出的那些“坑”！

中国“最牛”程序员，一人之力单挑微软