中国数据存储服务平台

软件与硬件更好的协同:Arm为开发者带来极致体验

据Arm分享,其有45%的工程师属于软件开发人员,他们从事大量的软件开发以及生态系统合作方面的工作,其中一些侧重内核GPU驱动的开发,但更多的工程师面向高层从事软件框架、性能分析工具、展示最佳实践等方面的工作。

Arm终端事业部生态系统及工程高级总监 Geraint North

Arm终端事业部生态系统及工程高级总监Geraint North从4个角度对Arm在软件及生态领域的工作进行了总结介绍。

向64位的迁移

安卓移动生态系统向64位架构的升级过程非常漫长。

10多年前,首款64位架构的Arm CPU就已经推出,面世两年之后,安卓的生态系统其实就已经能很好地利用它的能力。但目前,基于32位架构的依然存在。

“2022年,我们在64位的投资确实受到考验。”Geraint North介绍说,升级的挑战在于安卓生态系统具有极大的多样性,除设备的种类,合作伙伴类型和数量,迁移意味着大量的时间和成本,因此,产业链不同角色之间必须有大量的细致协调。

但是,向64位迁移是不可阻挡的趋势。

64位的优势在于,更大的地址空间提供了更高的安全性,而作为大部分操作系统标准功能的地址空间布局的随机化加载(Address space layout randomization,ASLR),提升了攻击者定位正在攻击的代码或者数据的难度。此外,64位指针在顶部提供了大量的空间,方便采用PAC签署指针、用MTE来进行内存标记。

64位:最高效的移动用户体验

SpecInt2006性能测试展示了六年前发布的32位Cortex-A76与今年发布的64位Cortex-A720之间的性能差距。看得出来,二者性能随着时间的推移在不断加大,最后一个支持32位代码的Cortex-A710提升了36%,这是32位性能的最佳表现,但却是32位的“末日辉煌”。

支持64位的Arm Cortex-A715/A720其性能逐渐攀升。Arm正借助软件的力量在把时间和投资聚焦在64位路径的优化之上。

事实上,早在几年前,Arm就开始从CPU和操作系统中逐渐剔除32位的历史遗留问题,向应用开发者证明向64位的过渡在真实发生,并且为他们支持64位的平台提供额外的助力。

“随着去年十月谷歌Pixel手机推出仅支持的64位的安卓配置,32位架构的旅程终于要走完了。”Geraint North长舒了一口气。尔后,MediaTek推出首款仅支持64位性能内核的安卓SoC,现已被广泛部署到许多的高端手机中。

Google在应用商店向64位过渡这方面的工作受到Geraint North的好评。他表示,早在2019年1月Google就为开发者提供了非常明确的时间表,于2021年8月停止向具有64位功能的设备提供32位的应用程序。2022年,Google已经完成了向64位迁移的所有准备工作。

因为应用商店的庞大数量,在中国推广64位的应用生态系统挑战更大,但出乎Geraint North意料:在顶级OEM开发商支持下,Arm在中国推动64位的工作进展非常顺利——报告显示,截至2023年3月30日,OPPO、vivo、小米等主流应用商店前万款应用支持率高达93%,所有应用支持率达到90%;排名前1000位应用的支持率几乎达到了100%。

谈到64位下一步的发展方向,Geraint North表示,Arm正在重点关注数字电视和机顶盒两个领域,语音控制摄像头进行视频会议和沉浸式高端游戏领域也有很大的市场潜力。

安全技术部署

随着更多软件的出现,数字化正在支持越来越多的工作、生活方式,越来越多的数据也在它生命周期某一个点上推动Arm。

Arm非常重视软件至关重要的安全性和稳定性并致力为开发者提供可靠、易用的安全功能。

根据NIST 2023年4月发布的最新报告,通用漏洞评分系统(CVSS)指标正呈现上升态势,2021年有20,000多个漏洞,包括未能验证网页上字段、SQL注入型攻击等等。

在众多的漏洞中,Arm对白色的越界写入(CWE-787,图中快速上升的白色线条)保持高度关注。CWE-787是一种内存攻击形式,可以修改索引或执行引用缓冲溢出的内存位置,损坏数据或导致系统崩溃。

Armv9架构CPU首次引入的安全技术有效地化解了这些难题。这些技术包括内存标记扩展(MTE)、指针认证(PAC)和分支目标识别(BTI)等。

关于MTE技术,前文已经有过详述,此处不再介绍。PAC是指在调用函数时生成并存储返回地址的加密签名,在函数返回时使用它来验证返回地址;BTI限制间接分支指令(BR或BLR),使其只能针对BTI指令。

PAC和BTI的联合应用,对代码跳转进行了更严格的控制,使得攻击者很难将现有代码的片断用于不法攻击;即使找到了覆盖指针的方法,但因为每个函数被调用时连接寄存器都会被清零,哪怕是突破沙盒后攻击者可以访问的代码几乎无迹可寻,所以仍难以真正覆盖任何代码。也就是说,如果有人以某种方式修改了内存地址,Arm也将不予认证。

PAC/BTI的安全性得到了市场的认可。

据Geraint North介绍,开源的网络浏览器Chromium是Google Chrome浏览器和微软Edge浏览器的基础。全球70%的页面浏览量来自于Chrome原生的浏览器,Chromium基于大量个人数据访问得出这样的结论:70%的安全漏洞报告由内存引起。

过去三年来,Arm和Google开源社区合作,用PAC和BTI全面保护Chromium。

Chromium作为一个大型的开源项目支持了大量的开源分支。Arm不得不为这些项目延伸出的各种Build、编译器、内核等增加PAC和BTI,并采用Arm系统模拟器Fast Model开发所需的软件功能,基于Chromium所依赖的代码库在流片前完成了所有的工作。

另一个案例是Unity。Unity是移动开发最常用的平台之一,70%的顶级移动游戏基于该平台开展创作。2022年Unity也启用了PAC/BTI,这对消费者来说绝对是个利好——只需简单地勾选,就能够实现安全保证。

具有PAC/BTI功能的设备应用已经一年,在生态系统中的部署速度提升很快。

提升Armv8性能的同时释放Armv9的能力

按照SPECint2017的标准评判,过去三年来,Arm处理器的性能已经提升12%。

尽管Armv8架构已经非常成熟,但Arm仍然持续冲击新的高度,以推动安卓生态系统运转。聚焦于可伸缩矢量扩展(SVE2)、设法提高支持多语言、可实现源程序动态编译的编译器和虚拟机的LLVM(Low Level Virtual Machine)的性能,是Arm的一个重要方向。

一年前,Armv9引入了全新矢量架构SVE2,进一步释放了性能的潜力:一是确保其代码生成质量尽可能好一些、快一些,达到甚至超过Neon(基于Arm平台对Single Instruction Multiple Data技术的一种实现,可以理解为SVE2、SVE的前身),保证LLVM可以向量化,同时增强LLVM,使其能够对Neon无法做到但SVE2可以做到的工作进行矢量化;二在LLVM中引入函数多版本,允许Neon和SVE2代码轻松共存,并在运行时自动选择合适的版本,以简化操作。

Arm Fast Model对于流片前的功能也提供了非常有益的帮助,大幅降低了性能增益方面的风险。

SVE2非常适合图像处理。但Arm对Halide也非常感兴趣,后者是一种非常适合以高性能的方式表达图像和数组处理操作的C++语言,因为只需要描述一次算法就能够为不同的指令集生成各种不同的高效的代码而受到开发人员的青睐。

Geraint North介绍说,Arm围绕SVE2在最新的CPU技术中挖掘更多的性能,在Halide方面也验证目前的工作方法。由于它使LLVM作为代码生成器,所以Arm与LLVM的合作将有助于Halide。

安卓动态性能框架

Arm的技术更新离不开众多开发者的支持。

据Geraint North介绍,Arm建立了Android适应性框架的目标,一直努力开发适应性工具和库,以实时了解和响应不断变化的性能、温度和用户情况。过去几年来,Arm获得了大量的反馈。

Android适应性套件由四个关键组成部分组成::APDF Hint API帮助系统根据游戏的运行情况对CPU升频或降率;APDF Thermal API为开发者提供数字信号,以了解与热阀值的距离;游戏模式API向开发者提供关于用户性能或电池偏好的建议;游戏状态API告诉系统正在做什么,动态调整以适应游戏性能需求的最佳状态。

已有开发者已经利用这些工具实现了最大的增益。

如将APDF Hint API集成到Pixel的SurfaceFlinger,可降低50%的掉帧率,并节省6%的电量,在Chrome浏览器和安卓地图中还发现了节省能耗的巨大潜力。所有这些,都只是APDF Hint API卓越性能的一部分。

使用Unity自适应的功能,Arm与Google合作展示了APDF thermal API的优势。演示数据显示,Candy Clash运行在第6分钟后,热状态升级到第一级,在第18分钟的时候,热状态达到警戒值,APDF Thermal API立即启动,动态改变场景的渲染质量,避免触发设备的关闭。

“安卓动态性能框架提供了一个一致的API,让开发者可以针对整个安卓生态系统进行开发,这就是Arm给合作伙伴提供了强大潜力来实现自己的差异性,并且尽可能利用到这些技术让API装备自己。”在Geraint North看来,这是Arm硬件和软件协同工作,为提供最佳消费者体验的又一个实例。



未经允许不得转载:存储在线 » 软件与硬件更好的协同:Arm为开发者带来极致体验
分享到: 更多 (0)