华为公布的方舟编译器到底对安卓软体生态会有多大影响?

问题描述:华为在P30的发布会上,公布了方舟编译器,并宣布开源,称可提升app性能。这对于开发者有什么影响和意义?对安卓现有的软体生态能有多大影响?对于华为本身来说又有什么意义?方舟编译器和现在Android 所使用ART有什么区别?相关问题Fred Chow 在华为做的哪些工作吗,会对华为编译器团队带来哪些影响? 问题补充 华为在2019年4.25日下午举行方舟编译器沟通会,介绍了一些相关技术原理,并公布开源时间 [图片] [图片] [图片] [图片] [图片]
, , , ,
梁山广:

开源规划来啦~

更新:2019-04-25 官方原理解释来啦!

——————原回答——————

对安卓生态影响很大啊~因为很快手机圈就要出龙舟、木舟、铁舟了……

还记得过去一年被各种turbo支配的恐惧吗?

System Turbo、Game Turbo、AI Turbo、Center Turbo、Net Turbo、Cooling Turbo、Dual Turbo、Multi Turbo、Monkey Turbo、Charge Turbo…..

神马?不知道Monkey Turbo是啥?


养猫的哈士奇:

原答案:方舟编译器是什么?

爪哇岛上一位富豪家里有很多菲佣,富豪只会爪哇语,他每次用爪哇语吩咐管家需要菲佣干什么都是管家听完后一句句翻译给菲佣听,虽然效率不高但是语言不通没办法。某天,一位叫方舟的人来应聘管家的职位说:我能让菲佣干活更快,于是他成了新管家。这位叫方舟的新管家给富豪建议:给我一个手册,写好菲佣每天要干什么。方舟拿到手册后将手册翻译成菲佣的语言然后发给菲佣,从此菲佣再也不用听吩咐就知道该干什么了,干活变快了。

备注:爪哇岛是印尼小道,英文JAVA,也是JAVA编程语言的来源,JAVA是Android的主要编程语言。

方舟这位管家就是方舟编译器,什么是编译器呢?其实就跟这位管家一样充当了“翻译官”的角色,将程序员看的懂的语言(C++,JAVA等高级语言)翻译成处理器看的懂的语言(机器码,都是0和1的组合)。

不管是早期的电子管还是现在的半导体晶体管,这些计算的基本单位能识别的只有电平的高低,在计算机中我们就用0和1来表示。1和0的各种组合就是机器是能看懂的语言,也就是机器码。计算机的初期,人们就是用0和1来写成程序命令的,这种反人类的编码显然是程序员痛恨的,于是有了汇编语言,用字元来表示命令编码,这就方便了很多,但是大型程序依然不可行,C\C++,JAVA等高级语言应运而生。可以说高级语言是为程序员设计的,也是为大型的软体工程设计的,因此逐步诞生了面向对象编程的继承、多态以及回调、反射等机制,不管高级语言怎么变化,处理器能够识别的都只是机器码,编译器就承担了这个翻译转化的角色,这也是方舟编译器要做的事儿。

做好编译器并不容易

我们都学过英语,可是翻译并不是每个人都能做,《刺激1995》这部电影看过吗?《月黑高飞》这部电影看过吗?都没看过?那《肖申克的救赎》你一定看过吧,其实他们是同一部电影,这是陆港台三地根据英文名《The Shawshank Redemption》的不同翻译,是不是差异很大?

就像这个电影名字的中英文翻译一样,要做好编译器也势必要对上层开发语言和底层硬体都有非常深刻的理解,才能做好高级语言与机器码的翻译。

做一个编译器并不难,难的是做出一个能够高效准确翻译的编译器,并且进行长期的维护迭代,所以绝大多数厂商是不愿意碰触编译器也缺乏动力去改变的动力。当前最主要的编译器是有两个:GCC与LLVM。现代编译器的结构基本就如下图LLVM的结构差不多,分为前后端,前段主要是处理程序员用的C/C++,JAVA等,后端主要处理硬体架构相关的优化。方舟编译器应该也是如此,具体的实现如何要等开源后才能得知了。

干掉虚拟机

当今移动终端领域分为IOS和Android两大阵营,说起IOS很多人会说“快!流畅!”。这是建立在苹果强大的A系列处理器,精心设计的swift语言,集成swiftc编译命令的Xcode工具,高效的IOS系统,严格的权限管理等基础上的快,可以称之为软硬体结合一体化的典范。

反观Android阵营,处理器性能在不断提升,JAVA开发语言搭配虚拟机的效率确实低了些,权限管理的问题也是老生常谈,如何改进呢?最直接有效的方式就是去掉虚拟机。

虚拟机很容易理解,顾名思义就是虚拟的计算机,虚拟机与真实的计算机一样无法直接识别程序员使用的高级语言JAVA,所以程序员在开发完成后需要编译为位元组码打包成DEX文件,与机器的硬体无关,这也是JAVA可以跨平台的原因。程序的执行终究还是要靠处理器来完成,所以虚拟机可以识别的位元组码文件还需要再次编译才能变成机器码来执行。换句话说程序员在用JAVA开发完成后需要编译两次才可以执行,而IOS只需要一次。

Android 在5.0之后将Dalvik虚拟机替换为ART虚拟机,这也是Android Run Time,在几经更改之后现在Android采用的是 解释执行+ JIT + AOT 的混合编译策略。一款APP在安装时不再进行AOT编译提高安装速度,第一次执行时边解释边执行,程序运行时,系统统计并记录经常用到的热代码编译为机器码(JIT),这些机器码在程序退出后会消失,系统根据记录分析这些热代码并在空闲时将这些热代码编译为机器码(AOT)。

AOT (Ahead of time):在程序运行之前或者空闲时将JAVA位元组码码编译为机器码。

JIT(Just in time):在程序运行时实时将JAVA位元组码编译为机器语言然后执行,应用退出后消失。

如果用翻译来描述现在的Android运行机制的话就是:一位CEO在记者招待会上用母语回答各国记者提问题,为了在座的记者都能听懂采用了同声传译(解释执行),翻译人员发现有些回答会重复多次就将这部分翻译成稿件,再遇到就直接念稿(JIT)这样会快一些,记者招待会结束后翻译在空闲时间将这些常用问答正式整理成稿件(AOT),这样下次再召开发布会更高效。如果在招待会开始前把所有要说的都写在稿件上直接念不是更高效吗?没错!这就是方舟要干的事儿。

方舟编译器舍弃了现在Android中的ART虚拟机,所以也不需要编译为位元组码文件(DEX),在生成APK安装包时直接编译生成适合的机器码,在终端设备上安装后直接就可以执行。省去了虚拟机,省去了JIT与AOT编译,采用了与IOS一样的方式,从机制上来说保证了App的快速运行。

说的这么好,“那么,古尔丹,代价是什么呢?

代价就是文件的体积会变大,与IOS安装包大于Android安装包一样的道理,以往的App安装包是打包位元组码的DEX文件,而方舟编译器的安装包是直接打包的二进制机器码文件。微博极速版为例,安卓9.0安装后37.5M(APK为9.7M),使用方舟后安装后约为50M(APK为23M)。在存储越来越大的今天,安装文件的大小已经不是主要问题,而且安装包安装完成后还会删除,所以不用太在意,至于体积大的游戏也不需要太在意,因为游戏的安装包中资源文件占比很大,这是与编译无关的。

去掉虚拟机还不够

有一家叫安卓的公司展开了一个新项目需要两个部门一起来完成,项目尽速有点缓慢,经过分析查找原因发现大部分时间都浪费在两个部门之间的协调上了。负责项目的主管认为这是公司架构划分不合理造成的,应该打破部门的壁垒,将联系频繁的部门合并成一个部门。从此这家公司的工作效率得到了大大的提升,这主要归功于这位叫做“方舟”的项目主管。

这样的“跨部门协调”导致效率不高的问题同样发生在Android应用身上。Android中ART虚拟机的存在是因为JAVA是Android APP的开发语言,但是绝大多数的APP因为各种原因还会用到其它语言开发的库,比如C语言。这样就存在一个显而易见的问题,这两个语言之间势必会产生调用、通信,这会产生很大的损耗。方舟编译器将不同的语言统一为

如何将不同的语言统一为同一个语言呢?有两种方式:

  1. 把不同的语言都翻译中间代码IR(Intermediate Representation),然后再由IR去对应不同的硬体架构翻译成二进制机器码。这样有一个好处就是,可以方便的支持新的开发语言与硬体架构。
  2. 都直接翻译成二进制的机器码,这样做需要对编程用的语言有非常深刻的理解,尤其是JAVA这样动态特性很丰富的语言。

编译器是重要突破

处理器、操作系统、数据库、编译器、编程语言这些是IT领域真正核心且基础的东西,也是我们落后美国的地方,在上层应用上我们应该处于领先的地位。晶元处理器这几年已经有了很大的起色,Android系统国产厂商也贡献良多,其它领域最好的突破口就是与这两者结合较为紧密的编译器。但是大陆有实力和动力做的公司屈指可数。

海思晶元的成功让华为决定试一试,2013年华为自研的编译器HCC取得初步成功,这也是华为在4G及5G时代移动通信领域取得领先的关键支撑,但是这还远远不够,要做编译器好必须要找行业大牛并长期投入。2014年,Fred Chow(周志德)加入了华为,这是编译器领域的顶级权威,著名的Open64编译器就是他主持开发的。Fred Chow发出了华为召集令,是否有千军万马来相应我们不得而知,但是可以肯定“前途是光明的,过程是艰苦的”,随后2012编译器与编程语言实验室成立,剩下的就是“十年磨一剑”了。

现在方舟编译器出来了,但是这只是一个开始,编译器是需要长期维护优化的。方舟编译器未来如何也不仅仅取决于华为,还要看谷歌的态度。

方舟编译器的价值

方舟编译器并不是为了“填补XXXX空白”,而是为了在不改变现有代码和编程习惯的基础上进行编译的优化,使得APP的运行更加流畅,方舟编译器的最终的目的是成为一个跨硬体平台、跨系统、跨语言的软体编译平台。编译器是一个桥梁,连接着上层的开发语言与底层硬体,又与操作系统紧密结合,掌握了编译器,更换开发语言,更换硬体架构甚至更换操作系统都会有很大的帮助。值得注意的华为成立的“编译器与编程语言实验室”从名字来看除了编译器还有编程语言,因为设计的原因JAVA脱离虚拟机后并非最好的开发语言,与其它语言的连接再如何优化也没有同一个语言方便,所以推出一个自己的编程语言可能是最佳的选择,然而这一步可能更加艰难,因为程序员要为此改变编程习惯。

拥有自己的编程语言,甚至在操作系统、硬体架构方面有所作为目前仅仅是幻想,也许有一天会实现,梦总是要有的。抛去幻想,面对现实,方舟编译器同样有着非常重大的意义。

  1. 锻炼人才:编译器的开发需要扎实的基本功,需要对编程语言和底层硬体都非常的熟悉,能够锻炼一批人才这是毋庸置疑的,这些技术人才是公司宝贵的财富。
  2. 为Android注入新活力:Android的诞生和维护主要归功于谷歌,虽然随着版本的迭代一直在进步但是多年来始终没有打破固有框架也因此无法再进一步,方舟编译器的出现显然为Android提供了另一种可能,华为已经从几年前的使用者变成了重要贡献者。
  3. 更好的用户体验:Android的生态需要谷歌、手机厂家、App开发商共同维护才能给消费者更好的体验,这点在大陆尤其突出,绿色联盟和统一推送联盟在着手治理App生态乱象,方舟编译器则是从系统框架层面提供了更深一层的优化。
  4. 提高效率:华为在ICT领域涉及的业务众多,晶元、Server、终端、IoT、云、通信,涉及的硬体和软体系统也很多,如果能够有一个统一的软体开发平台对自己本身也是非常好的,从晶元到编译器再到系统这种高度整合的软硬体一体化可以带来最佳的效果。

中国的IT行业发展的很好,但是在基础领域缺少突破,中国的IT业需要唐吉可德,需要为探索者鼓掌,当然面包也很重要,方舟编译器我认为干的不错。关于方舟编译器的具体细节与是非我们等下半年开源后再讨论。

大概率是导出APP的时候直接就是机器码,坐等开源。要了解这个问题首先要有几个基本的概念:高级语言,机器码(目标语言),编译,解释执行,还要明白程序/APP是程序员写的,这个程序是安装在操作系统中,最终由处理器执行的。

高级语言:Java、C艹等,这些语言是为程序员设计的,而执行程序的处理器是看不懂的;

机器码:程序的真正执行者是晶元,而晶元是由晶体管购成的,晶体管只有1和0两个状态,所以最终机器执行的内容都是一堆10,最初的程序也是这样的,为了便于理解就抽象成了指令,我们可以简单的理解为晶元执行的是指令集(指令集与汇编有一点点区别,也可以简单的理解为同一个东西)。不同的指令集同样的东西实现方式是不同的,因此X86上的程序放在ARM上是无法执行的。因此机器码与操作系统和处理器紧密联系,只能不能跨平台,华为的处理器或者EMUI中可能有一些特别的东西,这样就只能他自己用了。

图片来源于网路

编译:程序员写的APP最终是给处理器执行的,把程序员写的语言翻译成机器识别的语言这就是编译,这是在操作系统上完成的,处理器只能用来执行。以下图(来源于网路)为例,APP是在虚拟机中完成的这一步。

图片来源于网路

上图可以看到还是Dalvik虚拟机,这是5.0之前的,后来更换为ART虚拟机,具体的过程更迭参考 @weishu 的回答。(.so相当于win中的.dll)

边解释边执行是什么意思呢?相当于你去饭店要吃饺子要现包,这样会比较慢,直接执行就是直接端上来吃。

基本的概念(不准确,大致意思)了解后,你很容易就明白了,开发肯定是java,执行是机器码,安卓一直改变的就是解释执行,预编译,混合编译这些编译策略,因此我怀疑华为是直接机器码。即使这样也别太吹了,这么做需要技术实力也需要勇气但不是说世界第一,这样的话虚拟机就没什么用了,如果这样不知道谷歌怎么看。


张铎:

4.27更新

华为这几页解释真是。。。感觉就是把所有人都当小白,又沸腾了。。。不过反正8月就开源了,到时候看吧,spanner当年宣布之前大家也都觉得没啥大概就是个后台同步嘛,facebook还搞了一个跨机房方案出来讲,结果spanner真出来之后大家都惊呼我艹还能这样玩,希望华为也能这样吧

首先跨语言开销的问题,跟是不是全编译成机器码没什么关系,go本来就是机器码,但调用so还是必须走cgo,开销就是很大,这是语言特性本身决定的。Java走JNI调用为什么开销大,实际上你JNI里随便跑两句其实真没啥开销,也就是个函数调用,但开销主要就在java和c之间的参数传递上,因为java有GC,对象位置可能被挪动,所以C代码里要访问java的对象,要么就是拷一份,这个开销就大了,要么就得用一个特殊的方法pin住一块内存告诉JVM这段时间不能挪这个对象,等同于这段时间不能做GC,开销是小了但你一直不放开程序就OOM了。这事是语言本身的特性决定的,和编译器真没半点儿关系。

至于直接出机器码和不同程序用不同的模版优化,这俩本身就是矛盾的,不清楚华为为什么睁着眼睛说瞎话。静态编译相比JIT最大的劣势就是无法拿到程序的实际运行资讯来指导优化,所以编译界才搞了一大堆什么FDO(Feedback Directed Optimization),还有PGO(Profile Guided Optimization),通过实际运行程序收集一些资讯来指导优化。相当于要编译好几次。JIT天生就能干这个事情,反正我一边儿跑一边儿收集资讯一边儿优化就行。当然你可以说我在服务器编译,CPU比你手机强的多,吊打你的优化效果,但google印象里也早就在推这个事情了啊,就是收集大量用户执行的情况生成profile,然后在应用商店里直接编译,编译好之后用户再下载就是机器码了,不用自己再编译了。所以这事和方舟不方舟更没关系了,谁都可以做的事情。。。

最后是GC那个,安卓的GC实现我还真不了解,但我觉得怎么也不应该那么弱还是永远都STW吧。服务器端的java从CMS开始就不会一直都STW了,后来又出来G1,可以限定最长停顿时间,也可以增量整理堆,到Java11出来的zgc,可以在百G堆上把停顿控制在10ms以下(题外话,这个演算法似乎是一个收费版本的JVM早就提供的,也不是Oracle首创)。当然,不管G1还是zgc都是针对大堆(上百G)设计的,region based,不知道在安卓这种小堆上是不是能work。另外华为slides上那个图,是每个线程单独回收?那一个对象在多个线程之间共享怎么办。当然现在的堆分配器和GC演算法肯定都会考虑thread local的,所谓NUMA Aware,这个话题就大了不展开了。

最后,我看有人拿方舟对比LLVM,又让我想起当年和Fred Chow在一个饭桌上的事情了。有人说LLVM要开个会,Fred你要不要去看看啊,Fred说这我肯定不能去啊,我一去,他们肯定说你看Open64的老大都跑去LLVM的会了,Open64肯定不行了。

当然最后的事情大家也都知道了,不管Fred Chow去不去LLVM的会,现实还是不可逆转的导向了LLVM全面压过了Open64成为了一个和gcc并肩的项目,Open64事实上已经死掉了。

不知道是不是这个原因导致Fred Chow一定要自己开发一套新的编译器而不用LLVM,可能老爷子心里还是憋著一口气吧。总之希望他这次能成功吧,老爷子应该也60多了,估计也没有机会再来一遍了。

原答案

私下得到的消息,这事其实和编译器真没多大关系,实际是华为自己写了一套runtime,用方舟(其实不应该叫编译器,应该是一整套toolchain了,类似xcode)编译之后,不是安卓打包格式了,就是binary,然后链接华为自己的runtime

这就很容易解释为啥S10和P30p在图片那里差距这么大了,安卓本身的图片view的策略就是少缓存,华为修改之后的就和ios一样提前都缓存好,那自然吊打了

所以华为把toolchain都开源了其实也没啥,反正runtime在我自己这里,你拿到toolchain也只能给华为手机开发,除非你自己写一套runtime。如果你有这个实力自己开发一套runtime(其实主要是敢不敢),自己搞一套toolchain也很轻松反正现在开源的东西一大堆。

不过呢,这已经是摆明了在分裂安卓了,看google的态度吧。如果google忍了,可能华为再过渡个几年换自己的os。如果google直接翻脸,我觉得华为的算盘可能是打官司怎么也能拖个两年,只要暂时不在海外禁售,争取在这之前换到自己的os,就彻底和安卓还有google拜拜了


筷子:

这回华为的事儿,让我想起一件12年左右的一件往事。。

当时还在媒体,参加Acer发布新手机的会。在上海开。

此前在北京,阿里云OS跟海尔合作发布了一款三防手机。

而后阿里云OS与Acer合作准备在上海发布搭载云OS的一系列手机。

我们在发布会前一天飞到上海,入住酒店。第二天中午吃完饭,准备参加下午2点钟的发布会。

就在所有媒体都在大厅等待的时候,大概1点钟,公关公司的人召集所有媒体,通报了一个消息,发布会取消,所有人可以回北京了。

后据说Acer受到Google的压力,取消了整场发布会。Google的理由是Acer破坏了安卓阵营的生态。

近200家媒体的酒店、机票、会场、搭建、广告、等等的钱都是花了的。总体费用少著算也是好几百万了。。。

不过这回华为跟当年的Acer和阿里云OS不一样。。

相信结果也会不一样。。。


Cyandev:

看到很多回答里都有华为和三星的对比视讯,从视讯来看,应用开启速度华为略快可能是所谓的“方舟编译器”的作用。毕竟 Android ART 的 AOT 和 JIT 只针对 hot code(运行时经过 profile 认为有必要优化的代码,可能是 UI 相关或频繁调用的代码)做优化,而方舟可能就直接无脑全部预编译了了。

另外一点,ART 并非在应用一安装完成的时候就做 AOT,因为需要上面说到的 profile sample,应用跑过几次之后才有充足的数据来进行 profile-guided 的编译工作。并且有些 OEM 会配置 ART 的 daemon 使得设备必须在充电的状态下才能执行 dex2oat 工具编译应用。

从最后一张图看,我猜测“方舟编译器”应该并非给 ROM 厂商使用的吧。看来这是真・AOT!

接下来,视讯中大家的关注点都在“图片加载没有白块”这个问题上。我的直觉告诉我,这不是编译器和什么 JIT、AOT 的问题。因为不管是网路还是本地,图片加载都是有策略的,尤其是在 ListView 或 RecyclerView 中的场景。一次完整的图片冷加载需要若干步骤:有文件缓存时的读取文件到内存,文件缓存不存在时的网路请求,图片解码,绘制。其中 IO 操作可以并行,但是解码操作一般来说不会大量并行,都是在一定数量的工作线程中执行的。而且 Android 的图片解码都是直接 JNI 到 native 去做的,根本也不存在什么 JIT、AOT 的问题。就连图片的内存空间都没用 Java 的堆,也没有 GC 的问题。所以我不认为图片解码速度,AOT 和没 AOT 有什么质的区别,如果有,那就是代码写得太烂了。

回到图片加载策略的问题上,为了防止 ListView 滚动卡顿,有些 app 都不会在列表滚动的时候做图片的显示操作,甚至有的 app 会等待 ListView 完全静止时才开始加载图片,我不知道微博是不是这么做的。从视讯上看,我猜是的。那么这样的话,华为那边的微博有没有做特殊优化就不得而知了。

最后我想谈谈我理解的 Android 主要性能瓶颈。

不管是 Dalvik 时代的 JIT 还是 ART 时代的 AOT,我不太认为代码的执行效率影响太多用户体验。就我的安卓手机使用经验来说,我经常看到一些 app 在打开 Activity 的时候反应慢半拍,iOS 几乎不存在这个问题。这一点可能跟两个系统的架构差异有关。Android 中,页面的导航与基本单位一般来说都是 Activity(现在官方都在推 Fragment),启动和切换 Activity 是一个系统行为,需要 AMS 和 WMS 的配合以及大量的异步 Binder IPC 调用;而 iOS 这边是纯应用行为,开启新页面(ViewController)的时候不会与系统之间产生交互。新的安卓设备一般来说是很快的,但是装了很多国产应用以后你会明显感到速度的变化。大量后台 Services 与其他 Binder 的交互对性能影响很大。

动画和渲染方面 Android 与 iOS 也有很大差异,iOS 动画之所以流畅,是因为 iOS app 中的绝大多数动画(不包括 UIScrollView 滚动和 UIKit Dynamics 动画)都不依靠 app 进程的运行效率,app 调用 API 启动一个动画,Core Animation 就负责把动画的描述资讯通过 IPC 发送给 WindowServer,由它统一 render 和 composite,当然,动画也是它来负责的。

回来看 Android,动画是 app 进程驱动的,Choreographer 在每次 VSync 的时候触发一次回调,Animator 就会计算下一帧的属性值,通过 updater 设置到 View 上,设置过程如果不涉及重新渲染(onDraw)就直接调整 RenderNode 属性准备合成,如果需要重新渲染(很多组件的动画都需要,比如进度条),那就要准备 Canvas 来记录 DisplayList 等等…这些事都做完了,app 进程还要负责把所有 RenderNode 进行合成,然后把帧写到对应 Window 的 Surface 上,SurfaceFlinger 再在 VSync 的时候收集所有 Window 的 Surface 然后进行合成和渲染。总得来说,Android 这边 app 做的事太多了,app 进程做的事越多,系统越不好对其进行优化。反观 iOS,你触发一个动画,然后接着写个 while loop 卡死主循环,动画都不带掉一帧的。你放 Android 上试试?GC 一下你动画就得咯噔一下…

好吧,这么点破事扯了这么多,本人不是 Android 开发,有错误还望指出。


helanmouse:

众所周知,现代移动CPU的计算性能已经非常强悍,主要影响用户体验的地方,就是外设的操作过程,包括触控的反馈,磁盘的读取写入,无线网路的读取写入等等。

昨天一看到P30和S10微博照片图库开启对(diao)比(da)视讯,立马猜想菊厂这份2014年的I/O优化专利是不是已经实用化了?!


通过编译器和os支持分离出i/o执行的系统和方法

Support system and method for separating the i / o performed by the compiler and os

田琛 , 叶寒栋 , 胡子昂

摘要

本实施例提供了通过结合编译器和操作系统(Operating System,OS)技术进行输入/输出(Input/Output,I/O)执行的分离。 The present embodiment provides through a combination of compiler and OS (Operating System, OS) technology for I / O (Input / Output, I / O) to perform the separation. 所述实施例包括贡献多核或众核处理器中的已选核为I/O执行核,将基于编译器的分析应用于程序源代码的I/O区域的分类,使得所述OS能调度这些区域至所述指定的I/O核。 The embodiment comprises a multi-core or many-core processors contribution of the core is selected I / O execution cores, the program will be applied to classify the source code I / O area-based analysis of the compiler, so that the OS can schedule these designated area to the I / O core. 在程序源代码的编译过程中,识别所述程序源代码的每个I/O操作区域。 In the process of compiling the program source code, the identification of the source code for each I / O operation area. 在所述已编译的程序源代码的执行过程中,调度每个I/O操作区域在预先选择的I/O核上进行执行。 During execution of the compiled program source code, the schedule for each I / O operations performed on the area pre-selected I / O nucleus. 调度所述已编译的程序源代码的其他区域在其他核上进行执行。

http://www.google.com/patents/CN106030538A?cl=en​www.google.com


根据专利描述,菊厂利用编译器对程序代码的分析与理解,判断出哪些部分是I/O密集型热点区域,并在编译出的代码中插入特定指令告知OS。

这样OS就可以提前分配资源,将该部分核心代码通过OS调度器搬到指定的I/O核上面去执行,甚至能够使用专门开发的I/O调度器再次优化I/O性能。

根据专利中的描述,这样的优化可以显著的降低I/O中断打断计算核的概率,提升整体吞吐、降低系统延迟,甚至使用专门的I/O核还更加省电。

不过,这份专利最初应该是为了云平台等计算中心准备的,当然它也提到了在需要省电的移动平台上也有应用空间。

究竟有没有真的加入这项技术,只能期待菊厂哪天能对我们解密科普。


方舟编译器能够达成这样巨大的性能提升,绝不只是依靠一两项秘籍就能达的,一定还有更多的专利技术藏在其中。也只有隐忍多年持续的测试、反馈和创新,才能最终拉开和竞争对手的距离。

这大概就是研发型企业和非研发型企业的区别吧。

P.S 本回答引用文字和图片归属原专利作者所有。


Ashes:

搭载方舟编译器的P30PRO 还有S10+的对比图,虽然文化低不知道技术上有多厉害,只能一句卧槽了。如果开源所有安卓机都能用上,那么……嘿嘿

还有就是,猜测一下,就像评论里说的一样如果只支持麒麟。是不是以后华为自己出了操作系统,然后安卓里面所有的应用经过编译之后可以无缝对接到华为自己的操作系统呢?新系统的生态问题是不是就都解决了。

2015年2月份就已经申请专利了。这个局布了好久。


Eidosper:

算了不抖机灵了。

听说当年intel的编译器icc比gcc快一成左右,遇到amd处理器再负优化,后来还因为不正当竞争败诉了。虽然“i3战全家”不全是编译器的功劳,但是华为未来和cpu部分整合,仍然能较好的提升性能,达到“同是a76,麒麟不一样”之类的效果。

还是有用的。


川之剑:

有一个大家都忽视的事实。

大嘴已经在ppt以及会后采访都在“吹”这个是一定将来引领革命的,

如果华为公司认为大嘴真的可能会吹破了牛皮,起码会派一个副总之类的解释一下或者公关一下,但是可以看到华为丝毫不慌,甚至没有给大家提到关于这个编译器的任何具体细节。

说明他们的科研人员做好了充足的准备。当然,退一步讲,他们也不会草包到一个砸钱秘密立项的项目,会忽略Aorqu各位都不犯的小儿科问题,什么安卓早就在用什么了balabala。

最后一点,真正的技术大佬,此刻正在做实验写代码或者写论文,不会闲来无事来Aorqu磨嘴皮。


清风明月:

华为官方已经出来说了。

改动态编译为静态编译。

· 黑科技界新晋选手——华为方舟编译器
每次新版本的更新发布,总少不了“黑科技”的身影。EMUI 9.1此次更是带来了全新的华为方舟编译器。
要了解这项“黑科技”,首先要知道何为编译器。
编译器是连接人类世界与机器世界之间的一座桥梁,其性能,效率直接影响到最基础的消费者体验,是软体开发中的“皇冠” 。
现有的安卓系统上的程序往往需要一边转换一边执行,会占用较多的处理资源,影响程序执行的效率。
华为方舟编译器提供了全新的系统及应用的编译和运行机制,从动态编译变为静态编译,就是直接将高级语言直接编译成机器码,消除了虚拟机动态编译的额外开销,实现了开发和运行效率的兼容并举。

作者:华为终端
链接:https://www.zhihu.com/question/315196827/answer/653188793
来源:Aorqu
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

发表回响