一般而言,概念上“64位”通常与一台设备的中央处理器(CPU)紧密相连。一颗64位的CPU被设计用于操作64位字长的整型数据。相较于32位设备,通常意味着它能更有效地处理更大的数据块。在计算机体系架构的概念中,“64位”同时也指用于寻址和数据存储的寄存器宽度。理论上,64位宽的地址寄存器可以访问极其巨大的数字空间,上至2的64次方个独特的内存地址单元,而相应的32位寄存器只能涵盖2的32次方地址范围。对应于实际数字,通常这意味着高达18艾(180千亿兆)字节的海量存储,远超32位环境下仅仅4千兆字节的(容量)上限。同等条件下,一颗64位的处理器亦能比32位处理器更有效率地在更广阔的地址空间内处理(有效范围)更大的数据类型。尽管实际观测到的性能提升常常会被各种因素所左右,但整体而言,64位处理器已被证实代表着更快的运行速度,更低延时的数据吞吐,以及更迅捷的用户响应(依托于出色的软件实现)。
Arm何以64位?
64位CPU体系架构在当代计算(学)范畴内,意味着一系列的优越特性。Arm的“Armv8-A”架构于2011年问世,其所配备的宽寻址寄存器允许处理器无障碍访问远大于4千兆字节的地址空间。因此,一颗64位处理器相较于32位处理器,能以显著更快的速度处理更丰富的内存数据集合,进而颇为有效地管理海量数据结构(对象),大型的数组队列,与更宽裕的存储空间。
在移动计算领域内,Arm始终精益求精,开拓创新,持续不断优化32位与64位的处理器架构以及相关核心设计,通常广为人知的有AArch32与AArch64架构。随着安卓内核成功移植到64位,其余的操作系统核心组件,程序库,和应用程序如今都能完美运行于32位或64位两种体系下。Armv8架构向下兼容过往的32位Arm架构产品,然而对于前沿的算力挑战,如人工智能(AI),机器学习(ML),3D游戏,以及4K超高清显示等等而言, 伴随32位指令集(ISA)而生的种种限制为人们诟病久已!
英雄总有迟暮时,AArch32的架构实现历经多年演化,余下的改进空间日趋有限。在过去10年中,曾凭借出色的能效比带给我们无数欢乐时光的32位架构,已愈发难以被进一步提升,Arm倾力探索并实施的种种优化措施所能带来的增益也日渐式微。而与之相对应,投入同样的工程资源到64位指令集的研发与优化上却意味着巨大的潜在收益。
今天有无数运行于Arm CPU上的高效能移动应用,一个64位的体系架构将能保障它们未来的可持续发展,并孕育显著的创新机遇。以安卓生态的演进与谷歌推动的变革为一致愿景,业界同仁正在投入巨大的努力来确保安卓原生应用的开发能如期迈入全面支持64位体系的时代。
关于安卓生态的思考
64位计算的技术基础以及相关能力建设,多年前就已相继就绪,而今谷歌对开发者即刻开始64位迁移的建议驱动着整个安卓生态系统不断向前。许多兼顾iOS和安卓的跨平台开发者,受益于早先开发64位iOS应用获取的经验, “在需要的时候(安卓)64位移植工作将会进行得(相对更为)简单平顺” 。
对于很多应用来说,创建所必须的64位程序库并非难事,因为许多的开源库已经是类型安全的并经历了多年的反复考验。大部分使用Arm NEON指令的代码可以无需修改就能通过64位编译。编译器领域的长足进步,通常能自动生成更加出色和性能更好的(可执行)编码。今天,如果一个安卓应用是完全由Java语言写成的,那么目前的安卓运行时(ART)就可以保证其无需调整便能完美运行(于64位平台上)。需要特别注意的是,如果你的Java程序中使用了任何原生程序库或者原生SDK(以及NDK),都必须正确地包含相应模块的64位版本(而非32位)以便成功编译。以64位原生程序的移植为主题,Arm为开发者准备了一系列的博客和文档。
其他的安卓生态系统
某种意义上,就谷歌究竟能在多大程度上真正影响亚洲地区重量级应用商店生态的发展,存在不同声音,考虑到其在中国(大陆地区)甚至未能提供Play商店服务。因而谷歌的64位迁移计划,在这些显然不容忽视的市场里,也许从某些观点看来,并非那么不可或缺。然而,Arm通过与这些(自成一体的)安卓生态中,那些最具影响力成员们的接触与交流,确信他们都将拥抱64位指令集生态。与此同时,谷歌也公布了在Google Play应用商店提交应用,所需的全新安卓应用程序接口(API)等级,并且这一举措获得了来自中国的应用商店的积极配合与支持
64位(计算)的技术本质与裨益
64位安卓系统运行时比起它的32位对应副本的确需要更多的内存空间,这就意味着系统的最低内存要求有所上升,具体幅度也取决于设备的屏幕分辨率和像素密度等因素。一个32位版本的安卓系统通常只需要大约1千兆字节(GB)的内存就能启动,而与此同时,在64位CPU上运行时的最低内存容量要求可能会相应上升到1.8甚至2千兆字节。
最后一版仅支持32位CPU的安卓系统 “KitKat” 发布于2013年,以2014年诞生的 “Lollipop” 为起点,安卓系统开始同时支持32位和64位应用程序,这么说也许至少隐瞒了安卓系统(在兼容性方面)的部分潜力。受益于此,Arm得以在Armv8系列64位处理器架构上完美向下兼容所有现存的32位安卓应用程序。
对于安卓设备而言,有太多理由转向64位代码体系,例如:
- 增强的安全性
- 更高的性能
- 数量更多且字长更宽的寄存器
- 更高精度表现的64位数据操作
- 愈加丰富的指令集
- 其他32位代码无法利用的先进特性
64位编码中包含大量位宽更高的指针变量,因而导致了应用程序的可执行二进制文件大小增长,当然用户同时也获得了访问更大范围内存地址空间的能力,进而能够操作更大的数据块以更快的速度载入文件到内存中。配合经过优化的代码实现,这一特性允许处理器事实上以更低的能耗,更快的速度来完成(全部)操作,从而整体上节约电力。
//纯64位设备//
伴随着安卓生态系统中64位应用数量的日渐庞大,在不断降低设备元器件成本的市场驱动力作用下,终有一天安卓平台上会诞生一大批的纯64位设备。对开发者而言,这意味着更低的研发成本(无需兼顾32位与64位),与此外各类纯64位设备所能带来的种种益处,包括更低的(硬件)复杂度,针对单一架构的深度优化,都无疑有助于一个更加强壮,健康,以及鲁棒的系统得以问世。
这里列出的,是一些力挺纯64位指令集安卓设备的观点:
- 额外的32位支持导致(处理器)微架构复杂度明显提升
- 由复杂性导致的最终分摊至OEM厂商的额外系统测试及验证成本
- Armv8.x的安全特性包括 安全验证,数据保护,利用缓解,以及安全内容交付等,都只能在AArch64架构上实现
- 在不断涌现和演化的移动应用场景(如混合现实,人工智能,机器学习,和网络应用)中具备更好的性能表现
- 单一运行时意味着更少的测试和维护工作量
- 仅支持AArch64架构的CPU整体上更为高效
如今的安卓智能手机同时支持32位与64位应用,这帮助我们实现了对过往安卓设备(和应用)的向下兼容性,从而确保了最为广泛的潜在受众群体。然而,与之相伴的成本和劣势正在不断累积,下面是一份(负面)特性的清单:
- (同时)支持多个指令集导致必须在指令缓存中进行预解码
- 保持多个版本安卓应用安装包(APK)导致的闪存空间浪费
- 双份的安卓“接合子”管理器实现所消耗的额外100多兆内存
- 更复杂的系统安全环境意味着更容易被攻击
- OEM厂商所面临的更高的验证成本
- 兼容T32代码导致解码器占用的(晶圆)面积翻倍
- Thumb16(某旧指令集)的解码通常构成应用代码解码阶段的关键路径(性能短板)
- 在AArch32架构体系上进行NEON™寄存器的重命名需要双倍的标注量
- 导致NEON重命名表(NEON / FP执行期间的每个时钟周期都会访问)占用30%的额外面积
- 导致NEON的(指令)发射队列需要30%的额外源操作数存储空间与传送网络
- NEON(指令)发射队列中的传送逻辑与寄存器匹配逻辑(实现)需要消耗额外50%的电力 – 指令发射队列是单个(处理器)核心中三分之一动态功耗的源头
Arm立足当下开拓进取
Arm正与合作伙伴们通力协作,以期尽可能地洞察是否在生态,技术,以及商务层面上存在任何不利于64位移植的(潜在)关键议题。当然,我们从来不认为在这一进程中,有任何必经的问题或意外。迄今为止,Arm已经从安卓应用开发者,游戏引擎开发者,芯片制造商,与操作系统供应商等处,获取了大量的积极建议。我们将持续密切关注安卓生态的发展,权衡64位应用的可用比例(与权重),从而保证这一决定性的变革在正确的方向上不断前进。
Arm一直以来都在与游戏引擎开发者们紧密合作,以保证各个游戏工作室能在2019年8月前,有充裕的时间构建,测试,并发布(64位的)安卓游戏产品。我们坚信游戏引擎开发者们始终引领着(技术)创新,并推动着整个安卓生态系统的性能包线延申至新的疆域。目前,正在进行64位移植的引擎合作伙伴,凭借尚未完全优化的初期产品形态就已观测到了至少10%的性能提升。
Arm始终专注于构建由一些列性能最优的产品组合而成的高能效套装。我们目前致力于,为那些在安卓平台上被广泛应用的关键程序库,运行时,浏览器,和引擎,引入更多的(软件)优化。在可以遇见的未来,通过向安卓应用开发者们提供更多支持,必将令整个安卓生态获益匪浅。
安卓应用的未来
如果应用原先是(完全)由Java™语言开发的, 那么开发者无须(为64位)采取任何行动,所有非原生程序均不受影响。 倘若应用是基于原生安卓程序库,那么也许需要一点额外的工作,取决于原先程序的书写方式。即使只是(为64位平台)重编译一份完美编码的32位程序,也或多或少需要修改其中的一部分。因此,对于游戏开发者(特别是有自研引擎项目或代码涉及底层硬件的),及早验证以防在整个生态加速跃迁时遭遇困难,显得尤为重要。
原作者:David Whaley