从 2023 年起，其所有新智能手机 CPU 内核都将仅为 64 位，且没有 32 位兼容模式。

2013 年，苹果就在 iPhone 5s 中使用了 64 位 A7 处理器，我们开始拥有支持 64 位的智能手机处理器。不久之后，64 位 CPU 同样出现在安卓手机中，不过所有这些 CPU 既能运行 32 位代码又能运行 64 位代码。

因此，我们从仅支持 32 位，到同时支持 32 位和 64 位，再到现在我们将要抛弃 32 位，进入只有 64 位的时代。这对安卓和苹果而言，又意味着什么呢?

智能手机中，每个像素、通过互联网发送的每一个数据、存储在闪存中的每个文件、播放的每个声音以及屏幕上的每一次触摸都由数字表示和处理。依靠 GPU 等其他组件的帮助，大部分处理由 CPU 完成。

处理器以二进制形式存储这些数字，为它们分配的空间以位为单位。位由 0 和 1 的二进制表示，8 位可以表示零到 255 之间的任何数字，16 位的范围从 0 到 65,535，而 32 位可以存储高达 4,294,967,295(即 4GB)的数字。

Arm 在其指令集架构的第 8 版(称为 Armv8)中引入了 64 位支持，并且在 Armv9 中继续支持 64 位。这两者也可选择性地向后兼容以前的 32 位 Arm 架构。这意味着原则上 Cortex-A 处理器可以运行 32 位代码和 64 位代码并在它们之间即时切换。用户不会注意到 32 位和 64 位代码之间的任何区别。事实上，三星的第一款 Armv8 SoC 就是

多年来，事情变得更加微妙。Arm 有一些基于 Armv8 的 Cortex-A 内核，其中某些只有 32 位(例如 Cortex-A32)，另一些只有 64 位(例如 Cortex-A34 和 Cortex-A65)。您可能没有听说过这些 CPU 设计，因为它们没有用于任何智能手机处理器。

如果你的机型搭载高通骁龙 855(或更高版本)处理器，或者基于 Kryo 4xx(或更高版本)的处理器(包括骁龙 480、骁龙 675、骁龙 720、骁龙 730、骁龙 765、骁龙 780G 等)，那么你的机型已经无法再支持 32 位操作系统。

随着 Cortex-X2 和 Cortex-A510 对 32 位应用程序的支持的下降，你不得不运行 64 位操作系统和 64 位应用程序。Cortex-A710 保持对 32 位应用程序的支持，这意味着任何无法脱离 32 位模式的应用程序都将被迫在 A710 核上运行。

Arm 就 64 位的转移发表了两项声明。首先，Arm 谈到 2022 年它所有的大内核都将是 64 位的，然后几个月后 Arm 又谈到 2023 年它所有的内核都将是 64 位的。听起来不错，不过 Cortex-A510(一个小内核)已经只有 64 位了，那么为什么是两个不同的截止日期呢?

笔者认为，我们将在 2022 年看到支持 32 位的新的小内核，此后一切都将是 64 位。

值得注意的是，我们谈论的是 Cortex-A 处理器，即智能手机、平板电脑、Chromebook 等中的 CPU，而不是在谈论 Arm 微控制器系列中的 Cortex-M CPU。事实上，Armv8-M(M 代表微控制器)只有 32 位。

放弃 32 位对安卓影响不大

好消息是 64 位的安卓是一项成熟的技术，完全放弃 32 位支持不会有什么很大的不同。

Unity(2018 年)。从 2021 年 8 月 1 日起，Google Play 将停止在支持 64 位的设备上提供没有 64 位版本的应用，这意味着这些设备上的 Play 商店将不再提供这些应用。

Google 提供了不同的工具和大量文档，让应用程序开发人员为切换到 64 位做好准备。对于许多应用程序，实际上几乎没有什么可做的，因为那些用 Java 或 Kotlin 编写的应用程序不需要更改。但是使用游戏引擎或第三方 SDK 开发的应用程序需要确保使用最新的 64 位版本。

由于搭载 64 位 Android 的设备现已上市多年，再加上 Google 努力确保 Play 商店中提供 64 位应用程序，因此最终只切换到 64 位将不会有太大的影响。

苹果更早放弃 32 位

那时，苹果就完全放弃了 32 位，从苹果 A11(在 iPhone 8、iPhone X 中能找到)开始，所有处理器都只有 64 位。

从 2023 年开始，所有 Cortex-A 处理器都将只支持 64 位。由于安卓支持 64 位，并且正在转向仅支持 64 位的应用程序且将转换地很顺利，因此您可能不太会注意到任何差异。如果您是苹果用户，那么在 iOS 和 macOS 上切换到 64 位已经有一段时间了。我没有听说过渡过程中出现任何重大问题。

对于其他 CPU 架构和其他操作系统，如 Windows 和 Linux，32 位支持将持续更长的时间。既然 Linux 开源，那么 32 位支持很可能会持续几十年。对于 x86-64 处理器上的 Windows，可能连一条清晰的道路都没有。

1.1 什么是FP16数据？FP16指令有什么好处？

FP16是半精度浮点格式，相比常用的FP32单精度浮点，数据宽度降低了一半。2016年Arm更新了Armv8.2-A Extension扩展指令集，其中包含FP16半精度浮点运算。Arm NEON向量指令长度为128位，一条FP32向量可完成4个单精度浮点数运算，一条FP16向量可完成8个半精度浮点数运算，使理论峰值性能翻倍。如果该指令用于加速网络推理，相比于FP32预期能达到2倍加速。

智能手机分为Arm32和Arm64位两种架构，其中Arm64占绝大比例，苹果从2013年9月发布iPhone5s后，所有机型全都是Arm64架构。在Arm64架构手机上，App编译为64位可以获得最大的性能，但Arm64架构也支持按照32位编译的APP运行，而Arm32架构无法支持按照64位编译的APP运行。因此出于机型覆盖率以及软件包大小的考虑，当前众多App只会发布32位编译的版本。

经调研，行业开源推理框架如ncnn、MNN等仅支持Arm64位FP16指令加速，这样32位App无法享受FP16指令加速效果。针对这个行业缺失，TNN在架构兼容、模型兼容、代码结构设计等方面率先进行探索，对Arm64位和Arm32架构均实现了FP16指令优化，让64位和32位App都能发挥硬件FP16向量加速的能力。

2.1 架构兼容性设计

由于深度学习网络的算子种类繁多，并且随着新模型不断被开发，算子类型也会随之增加，因此，难以一次性为所有层提供FP16加速。我们采用TNN中广泛使用的注册机制，以实现FP16加速的增量开发。实现如下：

③在运行模型的初始化过程，TNN根据layer_precision_map的信息，为模型中的每一层分发计算精度。仅当算子已支持FP16加速，并且运行平台具备FP16加速硬件时，该层才会使用FP16精度计算。当用户设置的网络精度为PRECISION_HIGH时，可以强制禁用FP16加速。

2.2 模型兼容性设计

部署时模型的算子各种各种，为了获得最大的性能，TNN支持模型按照FP32和FP16混合运行加速。对模型中已实现FP16加速的算子，TNN默认自动按照FP16加速，而对模型中未实现FP16加速的算子，TNN在静态图中自动插入Reformat层转为FP32加速。如下图所示：

在TNN的图优化过程中，当发现Pad层不支持FP16加速时（如图a所示），会在其输入和输出分别插入Reformat层。Reformat层负责将FP16和FP32数据格式以及数据排布做相互转换，以支持Pad层单独采用FP32计算，其余层仍采用FP16计算。

如果模型中存在多个相连的层不支持FP16（如图b所示），TNN的图优化机制会避免在这些层之间插入成对的Reformat层，以提高运行效率。

为了在32位和64位库中都支持FP16，整体代码结构如下图所示。其主要分为五个部分，通过CMake中不同的配置项，可编译出不同的target。各个部分的主要区别体现在针对不同Arm指令集实现了特定优化。

由上图可知，aarch32和aarch64 FP16指令代码独立于其他部分。因为编译FP16指令需要添加特定的编译选项，如果对TNN代码全局添加该选项，会导致编译器将选项应用到所有代码中，然后基于Armv8.2-A架构生成目标文件。

例如在Arm64 Target中，在编译Armv8指令代码时添加该选项，会生成一些Armv8.1或Armv8.2指令集中独有的指令。这些指令若在不支持v8.1和v8.2的Armv8 CPU上运行，会直接导致程序崩溃。因此，为了最大限度地提高兼容性，Armv8.2-A FP16指令代码被单独剥离，单独使用编译选项，避免影响其他部分。

综上所述，TNN库会同时包含两种架构的指令：

2.4 运行时兼容性设计

由上可知，TNN库中包含两种架构的指令。当运行64位或32位库时，若在不支持Armv8.2-A的CPU上执行Armv8.2-A指令，会直接导致程序崩溃，在运行时造成兼容性问题。

针对上述问题，在执行推理之前，TNN会判断当前运行的CPU是否在白名单中、是否支持Armv8.2-A。如果支持，则会运行FP16算子，否则仍然运行FP32算子，避免执行Armv8.2-A FP16指令。具体判断方式如下：

Register），根据该标志可判断处理器厂商和型号，例如Arm的Cortex-A55，海思的Cortex-A76 (HiSilicon)等。然后与维护的白名单比较，最终判断硬件是否支持FP16加速。

TNN已对部分算子实现了FP16优化，在64位和32位库中均取得了不错的加速效果，相比于一些开源框架也具备一定的性能优势，如下图中的对比数据所示。

在A76大核上，TNN的FP32和FP16性能均能保持前列。在A55小核上，Bolt框架针对A55单独做了特殊优化，在性能测试时效果会更好。但实际应用中，由于进程可能会在小核和大核上动态调度，A55特殊优化版本在A76大核上运行的性能较差，所以实际应用的表现不一定会好。TNN采取的是相对折中的实现，在大核和小核上都能取得不错的性能表现。

TNN已经对大量的实现细节做了封装，只需要对少量参数进行配置，就可以轻松获得FP16的加速。

点击「」可直接跳转链接

TNN工程的根目录下提供了各个平台的编译脚本，只需要在这些脚本的基础上打开TNN_ARM82_ENABLE，就可以将Armv8.2的优化代码编译到TNN的lib中，当前默认是OFF。

在初始化时，将precision参数设置成PRECISON_AUTO，TNN内部就会根据CPU的型号以及layer的实现情况自动去调用FP16的代码，当前默认是PRECISION_AUTO，所以不用做任何修改。

TNN当前正在与PCG光影团队合作，后续还会支持更多算子的Armv8.2-A FP16优化，同时也会尝试去实现Armv8.2-A的Dot扩展指令，优化在最新机型上的int8模型性能。