TGFC Lifestyle - Powered by Discuz! Board

标题: 没人转吗，算是华为官方对方舟编译器的说明 [打印本页]

作者: 春熙 时间: 2019-8-8 17:38 标题: 没人转吗，算是华为官方对方舟编译器的说明

posted by wap, platform: Android
https://media.weibo.cn/article?jumpfrom=weibocom&id=2309404402247382466594

内容不得不说真tm长，写的还行，还没看完，看完也不知道看不看的懂

作者: bsseven 时间: 2019-8-8 18:38

posted by wap, platform: Chrome
说那么多有啥用，打开任何一个app都要看3秒广告，华为能干掉这个吗？

作者: dboy99 时间: 2019-8-8 18:48

posted by wap, platform: iPhone
确实是突破性的，以后华为的手机可以获得接近ios的执行效率

作者: Tobar 时间: 2019-8-8 18:50

Posted by Xiaomi MIX 2S
前面一大堆现状介绍都是从专业文章里面抄的，后面介绍华为的就没有任何实质性的内容

1。大数据编译器动态语义分析，编译时怎么进行动态语义分析？代码都没跑起来，是不是从哪里抄来的内容混到一起了

2。内存回收引用计数法和环消除算法，前面说华为编译器不用gc，这里又说华为破天荒用了gc里面著名的算法。还真是破天荒，java早就不用引用计数法了，而是用可达性算法（天生不存在环引用问题），华为这是开倒车？

感觉这文章就是东抄西抄凑合了一大堆文字出来，然后尬吹牛逼，这绝对不是华为官方提供的文章

作者: AzureZH 时间: 2019-8-8 19:00

引用:

最后，以Linux 创始人Linus Torvalds的名言结尾：

Talk is cheap. Show me the code！——空谈误国，实干兴邦！

这翻译太tm恶心了

作者: 流浪的枪骑兵 时间: 2019-8-8 19:25

posted by wap, platform: 小米

引用:

原帖由 @Tobar 于 2019-8-8 18:50 发表
Posted by Xiaomi MIX 2S
前面一大堆现状介绍都是从专业文章里面抄的，后面介绍华为的就没有任何实质性的内容

1。大数据编译器动态语义分析，编译时怎么进行动态语义分析？代码都没跑起来，是不是从哪里抄来的内容混到一起了

2。内存回收引用计数法和环消除算法，前面说华为编译器不用gc，这里又说华为破天荒用了gc里面著名的算法。还真是破天荒，java早就不用引用计数法了，而是用可达性算法（天生不存在环引用问题），华为这是开倒车？

感觉这文章就是东抄西抄凑合了一大堆文字出来，然后尬吹牛逼，这绝对不是华为官方提供的文章

有同感，涉及关键问题基本一句不提。
java代码直接变成机器码，指令集不一样怎么办？
难不成针对每套指令集做一套后端？这成本也太高了。
等源码出来再看。

作者: 睡睡平安 时间: 2019-8-8 20:42

posted by wap, platform: 小米

引用:

原帖由 @dboy99 于 2019-8-8 18:48 发表
确实是突破性的，以后华为的手机可以获得接近ios的执行效率

从何处看出来的？

作者: 卖哥 时间: 2019-8-8 21:32

引用:

原帖由 流浪的枪骑兵 于 2019-8-8 19:25 发表
posted by wap, platform: 小米
有同感，涉及关键问题基本一句不提。
java代码直接变成机器码，指令集不一样怎么办？
难不成针对每套指令集做一套后端？这成本也太高了。
等源码出来再看。

就是每套指令集做一套后端

三段式编译
高等程序语言-中间码-可执行代码
不同的高等语言用对应的解释器转化成中间码
而不同的指令集用对应优化器生成最终可执行代码

方舟按照之前的描述，主要改动有两个，一个是前端支持混合编译，而且混的相当彻底，把java自带机制都砸了；
另一个就是软件开发者以中间码提交，这本身按照三段式编译来说是不难的，但是现实没那么美好，本来三段式都在本地进行，那么调试还是比较便利的，但是递交发行那后端优化就脱离源代码了呀。除非真的做到单一环境下通过即可编译到其他指令集其他优化配置不需调试，那就非常黑科技，真做到可以说解决了编译这件事的万年毒瘤，怎么吹都不过分。

作者: lastescaper 时间: 2019-8-8 21:40

外行不评论

能华为实机出来再说吧

作者: 卖哥 时间: 2019-8-8 21:54

引用:

原帖由 Tobar 于 2019-8-8 18:50 发表
Posted by Xiaomi MIX 2S
前面一大堆现状介绍都是从专业文章里面抄的，后面介绍华为的就没有任何实质性的内容

1。大数据编译器动态语义分析，编译时怎么进行动态语义分析？代码都没跑起来，是不是从哪里抄来的内容 ...

具体不清楚，但是肯侵犯用户隐私做到这点并不难，编译的时候埋一些带编号的计数器暗桩，联网把计数同步到服务器，华为看一下手里的中间码对应的暗桩编号，就完成自学习了。

作者: 流浪的枪骑兵 时间: 2019-8-8 21:58

posted by wap, platform: 小米

引用:

原帖由 @卖哥于 2019-8-8 21:32 发表
就是每套指令集做一套后端

三段式编译
高等程序语言中间码可执行代码
不同的高等语言用对应的解释器转化成中间码
而不同的指令集用对应优化器生成最终可执行代码

方舟按照之前的描述，主要改动有两个，一个是前端支持混合编译，而且混的相当彻底，把java自带机制都砸了；
另一个就是软件开发者以中间码提交，这本身按照三段式编译来说是不难的，但是现实没那么美好，本来三段式都在本地进行，那么调试还是比较便利的，但是递交发行那后端优化就脱离源代码了呀。除非真的做到单一环境下通过即可编译到其他指令集其他优化配置不需调试，那就非常黑科技，真做到可以说解决了编译这件事的万年毒瘤，怎么吹都不过分。

真要是这样，这工作量确实无法想象
光前端就很麻烦了，这中间代码得复杂成什么样
另外这种做法不知道会不会影响java的一些特殊特性，比如反射之类

作者: masterfish 时间: 2019-8-9 06:49

引用:

原帖由 Tobar 于 2019-8-8 18:50 发表
Posted by Xiaomi MIX 2S
前面一大堆现状介绍都是从专业文章里面抄的，后面介绍华为的就没有任何实质性的内容

1。大数据编译器动态语义分析，编译时怎么进行动态语义分析？代码都没跑起来，是不是从哪里抄来的内容 ...

1、动态语义分析可以说是这次最有看头的地方，等开源了看大佬分析了，毕竟确实做出来了；
2、引用计数我认为远比java的暂停回收式gc好用多了，对内存的利用效率高多了。对于鸿蒙系统（方舟肯定是为鸿蒙服务的）这样的实时系统来说，几乎是唯一适合的gc模型。唯一的问题是循环引用的问题，但这其实是少数情况，可以单独处理。python是采用这样的，rust也是这种。
3、方舟我认为最牛逼的还是对多语言的融合，这个我觉得不会是完全创新，应该有llvm的底子，但是能够融合java、c/c++等，抛开傻逼透顶的jni，可以说功德无量了，同样，等开源了看大佬的分析。

[ 本帖最后由 masterfish 于 2019-8-9 06:51 编辑 ]

作者: masterfish 时间: 2019-8-9 06:56

引用:

原帖由 流浪的枪骑兵 于 2019-8-8 19:25 发表
posted by wap, platform: 小米
有同感，涉及关键问题基本一句不提。
java代码直接变成机器码，指令集不一样怎么办？
难不成针对每套指令集做一套后端？这成本也太高了。
等源码出来再看。

几个关键技术都提了，只是没有技术细节而已：
【1】gc垃圾回收采用引用计数，这就可以脱离java的沉重蜗牛壳的gc了；
【2】多语言联合编译，这是通过自创的中间语言IR来融合，能够摆脱狗屁的jni，可以说功德无量；
【3】指令集的问题没看源码不知道，但是对于华为来说，完全没有压力，因为它只需要做一套（arm）的就可以了，开源出来，也是可以让其他厂商可以自己做其他指令集的扩展。

作者: masterfish 时间: 2019-8-9 07:04

引用:

原帖由 睡睡平安 于 2019-8-8 20:42 发表
posted by wap, platform: 小米
从何处看出来的？

从一开始就看出来了。
ios的app是：编写程序--》编译成机器码--》安装到手机--》直接运行机器码；
安卓的app是：编写程序--》编译成字节码--》安装到手机--》运行时部分编译为机器码，再运行机器码；
你可以看到其中的效率问题。
虽然google已经对此有很大的改善，但是这个基本上还是没有本质的改变，可以说是安卓系统的原罪，但对于google来说这又不得不做，因为google不做手机，不同手机商的硬件不同，机器码也不同，编译为机器码就会导致兼容性的问题。
华为的工作，就是直接把安卓的整个过程变得和ios一样了，直接在开发机上就编译为机器码，安装的时候就是机器码，可以全速运行。
问题就是这样就导致app开发商会很头疼，因为要针对每个不同的手机厂家编译特定的版本了，这就会导致安卓app版本的分裂。
华为为什么会开源，估计就是不想背这个分裂安卓阵营的锅。

作者: masterfish 时间: 2019-8-9 07:07

引用:

原帖由卖哥于 2019-8-8 21:32 发表

就是每套指令集做一套后端

三段式编译
高等程序语言-中间码-可执行代码
不同的高等语言用对应的解释器转化成中间码
而不同的指令集用对应优化器生成最终可执行代码

方舟按照之前的描述，主要改动有两个， ...

现在看华为还是不敢做后一个，方舟编译还是在程序员的开发机上进行的，毕竟融合多语言，以及解析java动态语义必须参考源代码。

作者: masterfish 时间: 2019-8-9 07:13

引用:

原帖由 流浪的枪骑兵 于 2019-8-8 21:58 发表
posted by wap, platform: 小米
真要是这样，这工作量确实无法想象
光前端就很麻烦了，这中间代码得复杂成什么样
另外这种做法不知道会不会影响java的一些特殊特性，比如反射之类

华为毕竟不是慈善院，养那么多科学家和工程师不是吃白饭的，开发那么久肯定要有些成果。
但是也不是不能理解，毕竟llvm已经可以做到多语言融合了，看看方舟能够比之进步多少了。
另外把java的动态特性转为静态确实是这次的关键技术及亮点，就看开源后大佬们的分析了。
再另外，也别把工作量想得那么大，华为本身只是对多种编程语言（我认为主要是java/c/c++）的分析和融合，但是华为本身无需对多cpu指令集（涉及实际编译出来的机器码）进行综合，它只需对自家的麒麟芯片负责就好了，它开源出来，其他体系的需要的话自然会去扩展。

作者: 春熙 时间: 2019-8-9 10:50

posted by wap, platform: Android
昨天看完也没看懂多少东西

原博总结

作者: yfl2 时间: 2019-8-9 11:46

posted by wap, platform: Samsung

引用:

原帖由 @masterfish 于 2019-8-9 06:49 发表
1、动态语义分析可以说是这次最有看头的地方，等开源了看大佬分析了，毕竟确实做出来了；
2、引用计数我认为远比java的暂停回收式gc好用多了，对内存的利用效率高多了。对于鸿蒙系统（方舟肯定是为鸿蒙服务的）这样的实时系统来说，几乎是唯一适合的gc模型。唯一的问题是循环引用的问题，但这其实是少数情况，可以单独处理。python是采用这样的，rust也是这种。
3、方舟我认为最牛逼的还是对多语言的融合，这个我觉得不会是完全创新，应该有llvm的底子，但是能够融合java、c/c++等，抛开傻逼透顶的jni，可以说功德无量了，同样，等开源了看大佬的分析。

看不懂，引用计数是标记垃圾的方法，和暂停回收有啥关系？

作者: masterfish 时间: 2019-8-9 12:37

posted by wap, platform: Android

引用:

原帖由 @yfl2 于 2019-8-9 11:46 发表
看不懂，引用计数是标记垃圾的方法，和暂停回收有啥关系？

引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的变量指向其他位置，或者被删除了，那么就计数器-1，计数器变为0，就表示没有任何变量指向这块内存，那么就可以删除这块内存了。这整个过程不需要停下任何其他程序，资源损耗非常小。
引用计数的问题，是如果有两个指针互相循环引用，那末就会出现永远不会减到0的情况，造成内存泄露。
内存标记是java采用的垃圾回收机制，就是后台独立运行一个监控程序，监控所有的申请的内存是否被变量引用，一旦没有被引用，就证明这块内存可以回收，但是为了回收内存，监控程序会暂停所有的程序，然后将内存进行回收顺便处理碎片，所以会有卡顿，但不会有循环引用无法回收的问题。
现在python这类的语言，主要采用的是二者的综合，99%的内存是采用引用计数进行回收，剩下极少数循环引用的设置监控程序来处理。

作者: yfl2 时间: 2019-8-9 13:10

posted by wap, platform: Samsung

引用:

原帖由 @masterfish 于 2019-8-9 12:37 发表
引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的变量指向其他位置，或者被删除了，那么就计数器1，计数器变为0，就表示没有任何变量指向这块内存，那么就可以删除这块内存了。这整个过程不需要停下任何其他程序，资源损耗非常小。
引用计数的问题，是如果有两个指针互相循环引用，那末就会出现永远不会减到0的情况，造成内存泄露。
内存标记是java采用的垃圾回收机制，就是后台独立运行一个监控程序，监控所有的申请的内存是否被变量引用，一旦没有被引用，就证明这块内存可以回收，但是为了回收内存，监控程序会暂停所有的程序，然后将内存进行回收顺便处理碎片，所以会有卡顿，但不会有循环引用无法回收的问题。
现在python这类的语言，主要采用的是二者的综合，99%的内存是采用引用计数进行回收，剩下极少数循环引用的设置监控程序来处理。

你不要瞎说好么……
整天复制别人的装懂也是够了……

本帖最后由 yfl2 于 2019-8-9 13:11 通过手机版编辑

作者: wingfay 时间: 2019-8-9 13:32

虚拟机的好处是抽象硬件。
去掉虚拟机话，那么app适配放到开发端，那兼容问题是不是就会放大？

IOS运行速度快，是因为只用适配自己的系统就好了。那在开发编译时期就已经适配了，当然运行速度会好。

[ 本帖最后由 wingfay 于 2019-8-9 13:33 编辑 ]

作者: cj2047 时间: 2019-8-9 13:33

引用:

原帖由 masterfish 于 2019-8-9 12:37 发表
posted by wap, platform: Android
引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的 ...

???
引用计数法和可达性分析都只是判断对象是否可以回收的办法, 只能算垃圾回收机制中的一小部分东西

这篇文章讲得很含糊,具体细节还是只能等开发者大会和日后的开源了
个人猜测,看起来像是把java代码翻译成llvm,然后gc的话用类似苹果那套arc机制?
不过这块实在是不懂,不清楚华为要怎么搞才能解决其中的那些技术难点

[ 本帖最后由 cj2047 于 2019-8-9 13:41 编辑 ]

作者: yfl2 时间: 2019-8-9 13:34

posted by wap, platform: Samsung

引用:

原帖由 @cj2047 于 2019-8-9 13:33 发表
???
引用计数法和可达性分析都只是判断对象是否可以回收的办法, 只能算垃圾回收机制中的一部分内容

他错误百出，啥都不懂，只是装逼罢了

作者: masterfish 时间: 2019-8-9 13:38

引用:

原帖由 yfl2 于 2019-8-9 13:10 发表
posted by wap, platform: Samsung
你不要瞎说好么……
整天复制别人的装懂也是够了……

本帖最后由 yfl2 于 2019-8-9 13:11 通过手机版编辑

你有什么料露出来看看？

作者: yfl2 时间: 2019-8-9 13:41

posted by wap, platform: Samsung

引用:

原帖由 @masterfish 于 2019-8-9 13:38 发表
你有什么料露出来看看？

没，只是看到你扯的实在太傻太low

作者: fanti 时间: 2019-8-9 13:46

posted by wap, platform: Samsung
我跟你讲，大陆人写的关于程序方面的书，内容，99%是翻译发行版里的说明

作者: 春熙 时间: 2019-8-9 15:16

posted by wap, platform: Android
我也转发一个酷安上的评论，这个比较好懂

在微博上看到钟文泽转了这篇长文，居然是关于造势很久的方舟，看完之后就在想酷安估计也该有人在讨论了。当然，在未开源之前细节未可知，我只是想说一些从文字中看到的东西。
emmm，还是说一下，本人是不知名985计科在读，专业课程和知识体系相关，所以不是小白评专业，当然说这个也不意味着要开始科普，只是说明一下我的看法是基于我的知识储备从文中总结，不是章口就莱…
直接先划重点吧…
第一，绕过虚拟机带来的资源消耗，将代码直接转为机器码。一看到这个我就想，这不是把编译汇编一起干了，技术细节未知，但文章告诉我们，方舟在编译和运行阶段解决了很大一部分动态语义的编译，也就是完成了带来不确定性的文法的编译工作（非常难），注意，这一部分，是华为设计拥有的一项核心专利。
第二，绕过JNI带来的开销的同时解决不同开发语言的互通问题。使用统一的IR来表示不同语言，编译成华为自己开发的一套机器码，注意，这一部分，依然是核心专利。
第三，代码优化部分，更倾向于让开发者使用方舟提供的预置工具和调度建议去调整代码，强调不改变开发者编码习惯，效果如何，开源后用了才知道，至于云端优化，先往后捎捎。
第四，引用计数法和消除环算法来避免安卓内存回收机制带来的很多卡顿，未强调专利，这部分算法应该是可以给大家观摩学习甚至优化的。
这四点其实原博下给了总结，所以我只是添了些细节，我真正想说的是，编译这项工作是十分繁杂且逻辑极其严谨的，看看文中对项目工程师的描述可见一斑，描述的绝对不会夸张。它的地位虽然不可动摇，但从事计算机相关工作的少有深入编译原理的，就算是学院派出身也少有投入编译怀抱的，它不像热门技术那样风光无限，受人欢宠，所以华为肯做这个项目且开源使用，无论其出发点是什么，对这项技术的发展和这方面人才的需求培养是有益的。另一方面，关键技术上华为拥有着核心专利，这个确实顶，佩服。至于效果好不好，谁用谁知道。[机智]

作者: hourousha 时间: 2019-8-9 15:42

其实没多少意料之外的东西，多语言编译成IR再通过不同后端对应不同平台，AOT编译同时支持部分动态语义，独立的垃圾回收器这些，其实都不是新鲜的东西。就好像几年前u3d的那个IL2CPP就是个类似的东西。

作者: MacPhisto 时间: 2019-8-9 15:45

引用:

原帖由 hourousha 于 2019-8-9 15:42 发表
其实没多少意料之外的东西，多语言编译成IR再通过不同后端对应不同平台，AOT编译同时支持部分动态语义，独立的垃圾回收器这些，其实都不是新鲜的东西。就好像几年前u3d的那个IL2CPP就是个类似的东西。

还没看到方舟的源码。看介绍感觉就是这个

作者: 流浪的枪骑兵 时间: 2019-8-9 17:36

从软件行业从业人员的角度来说这个事。这个事在软件行业是编译原理方向，这个方向很成熟，但也很少有人懂的很深。因为一般没需求。

所以，这个方向如果有新东西出来，一般都是很nb的。

稍微往细里说一点，听起来源代码编成IR再编成机器码，逻辑挺清楚的。但实际上不是那么简单。因为java的动态特性，代码在运行期是可以修改自身的。这是java的nb之处。我对编译原理的理解也有限，不知道IR能不能做到这一点。

说实话，我觉得华为支持的“java编译成机器码”，这里的java不是完整的java，而是java语言的子集。假如真的是这样，即使只是java子集，也是很nb的想法。不过这样就有可能会出现这几种情况：1. 部分应用无法编译；2. 部分应用编译后不能正常运行； 3. 部分应用需要特定修改以绕开编译器缺陷。而这几种情况，会严重影响编译器的推广。

而且，我曾经看过“很吓人的GPU Turbo"的详细分析，https://zhuanlan.zhihu.com/p/43887961 ，华为在技术营销方面是有前科的，也就是过份夸大自己的技术优势，而选择性忽略技术的缺陷。

所以，我觉得，只能等着时间和源码来证明华为到底做了些什么吧。

作者: momou 时间: 2019-8-9 17:38

引用:

原帖由 masterfish 于 2019-8-9 13:38 发表

你有什么料露出来看看？

不要理他，一个不学无术的喷子troll

作者: 雾桑 时间: 2019-8-9 17:44

posted by wap, platform: Chrome
喷来喷去没意义
等消费级产品出来用了就知道了，终端用户不用操太多技术层面上的心

作者: yang_yii 时间: 2019-8-9 18:21

posted by wap, platform: iPhone
不就是整合了点开源的东西，有个屁好吹的。
发布会的那些用词有几个是能较真的？什么分布式os，真正分布式的定义是什么大家不清楚么？
无非这些都是写给普通爱国用户看的而不是开发者看的

作者: somesun 时间: 2019-8-9 18:26

posted by wap, platform: iPad
这玩意开源的把, 等等看代码就是

作者: yfl2 时间: 2019-8-9 18:34

posted by wap, platform: Samsung

引用:

原帖由 @momou 于 2019-8-9 17:38 发表
不要理他，一个不学无术的喷子troll

你和他一样都是不懂装懂

这次你煽风点火很失败，因为他错的离谱，你也一窍不通，所以没翻盘机会……

本帖最后由 yfl2 于 2019-8-9 18:42 通过手机版编辑

作者: iamppz 时间: 2019-8-10 01:09

posted by edfc, platform: iPhone 7

引用:

原帖由 @masterfish 于 2019-8-9 12:37 发表
posted by wap, platform: Android
引用计数和标记是两种不同的垃圾回收机制。
引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就......

水平太低，我面的培训班学生都比你讲得好

作者: 轻轻聆听 时间: 2019-8-10 23:13

反正华为，牛逼，不买华为是汉奸

欢迎光临 TGFC Lifestyle (http://tgfcer.com/)