草莓の君 发表于 2019-4-12 16:33
https://www.bilibili.com/video/av49065935
p30p vs XSmax
看了下这个视频下面的评论。
似乎说现在除了一个微博极速版和华为自家应用，还没有其它东西适配了方舟。
这视频的效果是华为新搞的那个极速文件系统的效果。
这啥意思，意思是说我才用3成力你就倒下了？
卡普空 发表于 2019-4-12 16:31
私下得到的消息，这事其实和编译器真没多大关系，实际是华为自己写了一套runtime，用方舟(其实不应该叫编译 ...
跟谷歌bye bye是打算放弃中国以外的市场？如果是的话华为已经走火入魔了，“上帝要使人灭亡，必先使人疯狂”。
— from 📱 Poco F1, Android 9 of S1 Next Goose v2.1.2
EROFS 是华为这次在 EMUI 9.1 加入的文件系统功能，全称是 Extendable Read-Only File System，即「可扩展只读文件系统」。
这项技术最早在 2018 年被网友在 Linux 的开源社区发现，直到半年后的今天，这项技术终于在 EMUI 9.1 和我们正式见面。
你们怎么都只关注方舟。
这个东西不需要第三方适配，已经可以检验效果了啊。
搜到的这玩意的测试数据：
Kirin970 (A73 Big-core 2361Mhz, A53 little-core 0Mhz, DDR 1866Mhz):
compressionEROFS seq readEXT4 seq read EROFS random readEXT4 random read
ratio bw bw bw (20%) bw (20%)
4 546.7 544.3 157.7 57.9
10 535.7 521.0 152.7 62.0
15 529.0 520.3 125.0 65.0
26 418.0 526.3 97.6 63.7
35 367.7 511.7 89.0 63.7
48 415.7 500.7 78.2 61.2
53 423.0 566.7 72.8 62.9
66 334.3 537.3 69.8 58.3
76 387.3 546.0 65.2 56.0
85 306.3 546.0 63.8 57.7
94 345.0 589.7 59.2 49.9
100 579.7 556.7 62.1 57.7
测试结果上看低压缩比的下性能比传统EXT4要好近3倍，高压缩比的情况下性能也与EXT4相当。
zhenniuren 发表于 2019-4-12 23:51
这两者互相矛盾啊
不同游戏负载不同，有的可以降压也不崩，有的不行。
怎么一上来全是怀疑的，猴为这两年是真的很猛啊，企业级固态也搞起来了，主控相当牛逼，都是3d tlc可以吊打outel的p4x10那些
卡普空 发表于 2019-4-12 23:22
现在网上有一波人看见gt就是降分辨率，超频，关省电精灵。我都懒得回，反正这群人只相信自己。
—— 来 ...
不止GPU华为的另外几个turbo也真不是忽悠 确实有明显效果的爱否也专门验证过
widder 发表于 2019-4-12 15:36
并不高，牺牲通用性，也就是你只能从华为市场安装的应用有这个加成，华为专用 ...
到底有没有这方面的意思？我觉得应用商店针对自家机型编译机器码没任何问题，可以最大程度优化。JIT再优化能比原生机器码快我不信。
zatsuza 发表于 2019-4-12 16:07
问题是AOT并不一定比JIT快，他要实打实的加成只能用更优的代码生成来实现了
除开PPT吹逼，实现这一点以菊 ...
请问大佬，在哪些情况下，同样算法的JIT跑在JVM里能比原生机器码更快？
卡普空 发表于 2019-4-12 16:31
私下得到的消息，这事其实和编译器真没多大关系，实际是华为自己写了一套runtime，用方舟(其实不应该叫编译 ...
这是好事，关键要看华为自己这套运行时到底指什么，如果还是jvm类似的东西，那没什么意思，我不敢相信华为弄到地外技术能把jvm效率提升六成。如果是更加底层的接口，同时又能避免ndk开发的困难，那是真的突破。这里扯什么空间占用和代码硬件无关都是浮云，终端用户只关心使用体验，只要速度够快，占用空间翻倍都不是问题。
随便看看等方舟开源吧
https://i.loli.net/2019/04/13/5cb1243ad5b34.jpg
https://i.loli.net/2019/04/13/5cb1243bc5c52.jpg
—— 来自 HUAWEI HMA-AL00, Android 9上的 S1Next-鹅版 v2.1.2
奶香花卷 发表于 2019-04-12 16:05:55
我寻思华为码农这等实力都可以去湾区上班了吧，为什么要在这里996不是所有人都喜欢在美国生活、真的。
东亚是个压榨机器、但是往回跑的人并不少。
-- 来自 能看大图的 Stage1官方 iOS客户端
卡普空 发表于 2019-4-13 07:53
随便看看等方舟开源吧
重新转成so的话 ，基本旧应用兼容性就是凉凉，大量反射方法全玩蛋。而且能比之前快多少很难说。
unity的il2cpp方案实装了2年了 性能也就那么回事 倒是各种莫名其妙的bug
lvseqiji 发表于 2019-4-12 17:45
。。。我觉得吧，不要怀疑世界R&D投入第五的公司的软件开发能力好吧
投入第四那家公司的拳头产品在本区被喷的像屎一样
zhenniuren 发表于 2019-4-13 01:32
哪一款游戏降电压不掉帧？
降压不会掉帧呀，降频才会掉帧，降压会直接崩。
但是是这种情况崩那种情况不崩，所以如果有一个更细的表，就能在能效上挖潜。
defer 发表于 2019-4-13 09:07
投入第四那家公司的拳头产品在本区被喷的像屎一样
我猜猜是哪家。。是微软win10么？
widder 发表于 2019-4-12 15:36
并不高，牺牲通用性，也就是你只能从华为市场安装的应用有这个加成，华为专用 ...
不不不，当然不是指技术高玩，技术高玩的多了去了
而是指能够靠整体生态来弄出这么个玩法，整体能力的体现是很有意思的
shahito 发表于 2019-4-12 13:16
看了这帖，打了一段自己写的文字并发到了 zhihu 里 https://www.zhihu.com/question/319688949/answer/6488 ...
AOT这种事情根本就不要放到手机上来搞，既慢又耗电，商店直接发机器码安装包，体积大不到哪里去。打破脑袋省这么点空间意义何在？又不是嵌入式系统。你JIT优化到天上去，绝大多数情况下都不会比机器码更快。
机器码这个东西是个很神奇的玩意, 和运行环境高度耦合, 绝对不是你想的那样在A机器上编译, 拿到B机器上就能直接运行的.
编译器把程序变成机器码是个很复杂的过程, 这个过程中需要大量用到底层的各种信息, 包括CPU指令集, 操作系统提供的各种接口, 内存管理机制等等. 一个与运行环境完全耦合的程序, 其运行效率是非常恐怖的. 但代价就是系统耦合度极高, 基本不具备复用性和扩展性. 讲得直白一些就是一机一程序, 拿到另一台机器上就没法用
如果你同时部署过Java程序和C++程序就会发现这种有趣的区别. Java依托于JRE, JVM, 在Windows环境下编译的.class, 拿到Linux服务器上立刻就可以运行, 因为.class其实并不是真正的机器码, 运行时还要依托于JVM进行重编译, 这种做法降低一部分效率, 但是极大的提升了跨平台的通用性, 使程序和运行环境的耦合度大幅度降低.
C++完全不同, 写C++程序尤其是那些做外包的, 拿到需求第一件事就是先搭一个和生产环境尽可能接近的测试环境, Linux内核版本, 编译器版本, 驱动版本, 各种依赖库都要完全一样. 在测试环境上运行通过以后拿到生产环境还要再编译一遍才能拿来用.
知乎那个回答猜测了两种可能, 一是JIT + AOT, 二是在发布时APK已经被编译好了. 我觉得第二种可能性比较大, 但并不是简单的在打包APK时就进行了完整编译, 原因正如之前所说, 机器码和运行环境是高度耦合的, A环境下编译的机器码拿到B环境下未必能运行.
这其中的操作空间主要在这里: 手机不像服务器, 同一型号甚至同一系列的手机, 其硬件配置在程序角度来看并没有太大区别, 因此可以在编译器中预置手机型号的模板, 其中包含运行环境的底层信息. 这样编译完成后就是高度耦合的APK包. 当然这么做也不是没有缺点, 那就是这个APK只能在这个型号的手机上使用, 拿到其他手机上直接无法运行甚至出错.
Astroneer 发表于 2019-4-13 14:43
机器码这个东西是个很神奇的玩意, 和运行环境高度耦合, 绝对不是你想的那样在A机器上编译, 拿到B机器上就能 ...
照你这说法，ios的app编译是怎么做到一次编译多机型适配的？以及windows的exe又是怎么做到的？
—— 来自 HUAWEI PCT-AL10, Android 9上的 S1Next-鹅版 v2.1.2
uroko 发表于 2019-4-12 23:56
EROFS 是华为这次在 EMUI 9.1 加入的文件系统功能，全称是 Extendable Read-Only File System，即「可扩展 ...
只读文件系统这个好几个月前就有了吧，使用场景也只是一般拿来放kernel之类的，其他地方照样用ext4。
蓝色的风之精灵 发表于 2019-4-13 14:48
照你这说法，ios的app编译是怎么做到一次编译多机型适配的？以及windows的exe又是怎么做到的？
—— 来 ...
Windows没了解过, ios的LLVM只有过粗浅的了解. 简单说说
LLVM的大致底层原理是三相设计, 代码 -> Clang -> IR码 -> LLVM -> 机器码. 开发人员写好的代码会先通过Clang编译成IR码, 再通过LLVM编译成机器码. 如果设备配置有变动, 那么不需要改动IR码, 只需要针对新配置开发相对应的LLVM编译器则可以实现多机型适配.
至于IR码是什么时候变成机器码的, 我个人猜测应该是苹果商店审核的时候.
Windows的跨机型实现方法应该更low, 整个Windows其实可以说就是一个大号的虚拟机, 底层机器码和API的对应工作应该是在Windows安装的时候建立的, 开发者只需要面对API就行了, 基本不需要和底层打交道
本帖最后由 shahito 于 2019-4-13 16:44 编辑
lixianfyss 发表于 2019-4-13 13:55
AOT这种事情根本就不要放到手机上来搞，既慢又耗电，商店直接发机器码安装包，体积大不到哪里去。打破脑 ...
体积变大了下载也要点费电和费时间下载啊。另外现在手机自带的这种带反馈生成的aot因为能获得到的运行时数据的比你这种在非宿主机上的要多的多，所以aot后生产的机器码也比你说的这种质量高啊。现在手机上是可以重复多次aot的（不断进化），一些很多人可能永远用不到的代码，是可以不会aot的，也减少了机子里应用的体积，也比你这种全部aot的优势大啊。如果你是开发，你会在手机和编译时都加入aot吗？在手机上aot最后效果会比你开发机上编译好的情况的（现在play市场会分发优化信息，这个接近最后的时间也提早了很多）的情况下。另外按这种思路，一个事先aot并能在arm和x86上运行的apk是超级超级大的。
本帖最后由 shahito 于 2019-4-13 17:04 编辑
按zhihu帖里说的华为花了那么多功夫，我现在已经非常相信华为做了一套在各种方面都优化了很多的方案比现在google的这套好的，但是我感觉事先aot这套方案不是非常好，或者说aot只是显著提升安装后最开始的一段时间的体验。然后运行时在做了其他很多的其他的优化。
当然如果apk里都带so的话，那么android的apk会大很多，基本上体积可能会有点接近ios的app那样大了（当然稍微小一些）。而且对于ios统一的分发渠道来说，对于那么多国内的市场来说可能是一个振幅的负面效果的。一些市场为了照顾主流的机子的架构，编译的so质量只会趋向于universal，然后x86 更gg……再加上性能质量还没机子上的现在流程编译的aot的高……
另外其实首楼的那个视频很奇怪，完全不明白。因为weibo图片加载，网络应该是最重要和明显的（虽然可能weibo的代码质量怎么样也有关系），从相册里加载最重要的是io的速度。当然编译器和运行时这一套可以提升一些，我感觉不会那么夸张，所以我不太明白。所以我的第一个想法是不是s10的信号和io比p30的差……不过华为可能的确做了一些没人想到，但是可以提升这方面非常多性能的手段。
另外我感觉可以把华为这种开源叫 ppt 开源了……感觉我还是应该安心干点其他事情好……
董卓 发表于 2019-4-13 12:08
不不不，当然不是指技术高玩，技术高玩的多了去了
而是指能够靠整体生态来弄出这么个玩法，整体能力的体 ...
华为很想做下一个苹果啊
Astroneer 发表于 2019-4-13 15:57
Windows没了解过, ios的LLVM只有过粗浅的了解. 简单说说
LLVM的大致底层原理是三相设计, 代码 -> Clang...
windows是大号虚拟机你认真的么？
com了解一下？
真田丸 发表于 2019-4-13 17:07
不是同一个平台的app怎么比？为什么不找s10比
跨平台比没意义我懂，问题是过去这种比较印象中都是以iphone暴打所有收场。
win是虚拟机还行，我感觉隔壁虚片输了。
代码体积本来就没多少，多个几倍都不是问题，体积大的是多媒体资源
Astroneer 发表于 2019-4-13 14:43
机器码这个东西是个很神奇的玩意, 和运行环境高度耦合, 绝对不是你想的那样在A机器上编译, 拿到B机器上就能 ...
需要具体设备确认这个理由不能成立。厂家自己的手机硬件是什么难道自己还不清楚
—— 来自 HUAWEI LYA-AL10, Android 9上的 S1Next-鹅版 v2.1.0-play
看微博有说奶飞的app emui9.1显示不兼容、还真是厉害啊
-- 来自 能搜索的 Stage1官方 iOS客户端
shahito 发表于 2019-4-12 13:16
看了这帖，打了一段自己写的文字并发到了 zhihu 里 https://www.zhihu.com/question/319688949/answer/6488 ...
art profile 是 google play的机制
国内的应用市场应该都不支持吧
所以只有 本地针对 hot path的 dexopt
在某些比较冷僻的场景下 就是 解释运行-
dexopt对 一些长的方法也不进行优化，这一部分也会有提升
怎么说 全静态 总是比部分机器码 要快的
至于有没有到ppt中的效果，那只能说 仁者见仁了-。-
shahito 发表于 2019-4-13 16:43
体积变大了下载也要点费电和费时间下载啊。另外现在手机自带的这种带反馈生成的aot因为能获得到的运行时数 ...
为什么要生成在arm和x86上都能跑的机器码？完全没有必要，只需要在华为最新的几代手机上跑得又快又好就足够，适配范围绝不会比水果更大。ios安装包比apk大，但是也不夸张。
shahito 发表于 2019-4-13 17:01
按zhihu帖里说的华为花了那么多功夫，我现在已经非常相信华为做了一套在各种方面都优化了很多的方案比现在g ...
不要重复说什么照顾主流架构或是硬件兼容性问题，极端点说商店的安装包就两套，侦测到你手机是我支持的机型那就给你发完全编译版安装包，否则就发原来的普通apk。这样下来手机和商店的核心竞争力都有。
