“64位”

我们先来谈谈“64位”这个术语及其含义。大家对于这个术语一直比较困惑，很大一部分原因在于，它没有统一的、约定俗成的定义。然而，在大体上却达成了一些共识，尽管这些共识并未为大众所知。

“×× 位”CPU通常是指两个部分的宽度：整数寄存器的宽度和指针的宽度。值得庆幸的是，在大多数现代CPU中，它们是一致的。“64位”通常是指CPU有64 位整数寄存器和64位指针。除了搞清楚“64位”所指的对象外，明白非“64位”所指的对象也十分重要，这些对象通常包括以下几种。

• 内存（RAM）地址大小。这一数值（关系到硬件可支持的最大内存）与CPU的位数无关。ARM架构的内存地址通常从26位到40位不等。
• 数据总线大小。CPU从内存或缓存中获取的数据量也与CPU的位数无关，某些CPU指令可能需要特定大小的数据，但在实际应用中，既可一次获取多条指令， 也可多次获取一条指令。上一代iPhone就已经以64位块为单位从内存获取数据了。在PC中，块大小最高可达192位。
• 与浮点运算相关的参数。FPU寄存器的大小和内部设计是独立的，ARM架构采用64位FPU已颇有段时间了。

“64位”的优点与缺点

尽管64位与硬件可支持的最大内存无关，但便于单一程序使用更大内存。在32位CPU中，单一程序仅有4GB地址空间，减去被操作系统和标准库所占用的部 分，只剩1～3GB可用。如果一个32位系统的RAM超过4GB，单一程序很难充分利用全部空间，除非开发者耍些小聪明，例如直接命令操作系统按需求分配 内存，或将程序拆分成多个进程。但在实际应用中，很少有程序这么做，因为编程更麻烦，还会有损性能。系统拥有更多内存的好处是，能同时运行多个应用并减少 硬盘缓存。这样固然不错，但难免有个别程序需要使用更多内存的情况。

即使对于物理内存较小的系统，更大的地址空间也有帮助。内存映射文件是种有用的结构，在32位系统中，程序不能映射大文件（通常是指超过几百MB的文件），而64位系统的可用地址空间更大，不必有这方面的担心。

不过，增加指针宽度有个严重的缺点：在所有其他条件都相同的情况下，单一程序在64位CPU系统中更占内存。因为指针本身也需要存储于内存中，在64位系统 上，这个空间增加了一倍。而大多数程序运用指针很频繁，所以额外占用的空间往往不少。这给缓存带来了压力，从而导致性能降低。

简而言之，“64位”可以提升某些应用的性能，并使内存映射文件这种编程技术更易用。不过，它也会因占用更多内存而降低性能。

ARM64

iPhone 5S的64位CPU是配有更宽寄存器的ARM处理器，与32位ARM架构相比，64位ARM架构包括以下重大变动：首先是名称的变化——它的官方名称为 “AArch64”，但这个名字读起来很绕口，敲起来也别扭。苹果称它为ARM64，我也更倾向于用这个名字。

较32位ARM架构而 言，ARM64的整数寄存器数量增加了一倍，32位ARM架构有16个整数寄存器，其中1个是专用的程序计数器，还有2个用于堆栈指针和链接，其他13个 则作一般用途。而ARM64位架构有32个整数寄存器，包括1个专用的零寄存器，1个链接寄存器和1个帧指针寄存器，还有1个寄存器预留给平台，另外28 个则为通用整数寄存器。ARM64上可用浮点寄存器的数量有所增加。32位ARM处理器有32个32位浮点寄存器，还有16个额外的64位寄存器。这些寄 存器的结构有些特殊，可被视为等价于16个重叠的128位寄存器。ARM64则将其简化为32个128位寄存器，且没有重叠。

寄存器的数量 会对性能会产生巨大影响。与CPU相比，内存要慢得多。与CPU处理一条指令的时间相比，读取和写入内存都需要更长时间。CPU试图通过引入缓存来缓解这 一差距。但与CPU内部的寄存器相比，即使速度最快的缓存也慢得多。更多的寄存器意味着更多数据能存储在CPU内部，这降低了内存访问频率，同时提高了性 能。

除了增加寄存器数量，ARM64也为指令集带来了重大变化。大多数32位ARM处理器可基于运行时条件寄存器的状态执行条件指令，这使 得在编译if等语句时无需分支。不过这种方式引入的麻烦多于便利，因此ARM64取消了条件执行。ARM64的NEON SIMD单元完全符合IEEE754双精度标准，而32位版本的NEON SIMD单元只支持单精度。ARM64还增加了专门的AES、SHA-1、SHA-256加密指令。这些指令也许对普通应用帮助不大，但对特定领域的应用 来说价值无穷。

Objective-C Runtime变化

在Mac OS X 10.7操作系统中，苹果引入了标签指针，这种指针允许某些类和其少量实例数据完全存储在指针中。这样在使用某些类时（如NSNumber）就无需分配内 存，并提升性能。标签指针仅支持64位架构，一部分原因是受二进制兼容制约，另一部分原因是32位指针预留的数据空间不足。之前的iOS系统都不支持标签 指针，而在ARM64位架构中，Objective-C Runtime已包含了标签指针，因此也可以享受Mac系统所具备的便利了。

尽管指针为64位，但在实际使用中，这些位数并不是都用上了。例如X86-64的Mac OS X系统仅使用了其中的47位。而ARM64上占用得更少，目前只有33位。只要未被系统全部占用，这些指针就能用于存储数据。这是Objective-C Runtime演进史上最重要的变化之一。

另作他用的ISA指针

Objective-C对象是连续的内存块，这个内存块中第一个指针大小的部分称为ISA。一般来说，ISA是一个指向该对象所属类的指针。

不过这么大的空间仅作为指针有点儿浪费，尤其是在64位CPU上。运行iOS的ARM64目前仅使用了一个指针的33位，而其余31位则另作他用。另外，类 指针还需要对齐，这就释放了另外3位，于是ISA指针中共有34位可另作他用。苹果的ARM64 Runtime正是利用了这一点使性能有了大幅提升。

不过，最重要的性能提升也许得益于内联引用计数。几乎所有的Objective-C对象都采用引用计数（NSString文字等常量对象是例外），这使得修 改引用计数的操作极为频繁。尤其对于采用自动引用计数的系统来说，资源消耗非常高。因此，提高引用计数的性能变得至关重要。

以往，引用计数 并不存储在对象中，因为ISA空间不足。当然，我们可以为每个对象专门分配一块空间用于保存引用计数，但这会占用更多的内存空间。对今天的系统来说，额外 的空间也许不算什么，但对早期的Objective-C系统影响严重。由于这样的原因，引用计数被系统存储在了一个单独的表中。

于是，当为对象增加新引用时，Runtime会执行以下操作：

• 获取全局计数哈希表；
• 锁定表以确保线程操作的安全；
• 查询表中对象的计数；
• 增加计数，并将新值重新存储到表中；
• 解除锁定。

这些操作非常缓慢！即使用最快的哈希表，也没有直接从内存访问来得快。

对于ARM64，ISA字段中的19位用于内联存储引用计数。这意味着，增加对象引用的步骤可以简化为：在ISA字段正确部分执行原子操作加一。

仅此而已！速度将会快得多！当然，还有一些极端情况需要处理，真正的操作会略微复杂一些。

以往在回收Objective-C对象时，需要执行大量清除工作，跳过其中不必要的步骤，就可以提高性能。利用剩余的可用位，还有其他一些方法可使回收对象的速度更快。

将上面提到的所有优化集合在一起，ARM64的性能优势就变得非常明显了。根据我自己不太严格的性能测试显示，在iPhone 5S 32位模式下，基本对象的创建和销毁大约需要380ns，而在64位模式，仅需200ns。如果某类实例曾有过弱引用并与对象集合关联，32位模式下的耗 时上升至约480ns，而64位模式下保持不变，仍为200ns。

结束语

“64位”A7处理器既不是一种营销手段，也不是一个能催生创新应用的巨大突破。真实的情况是，它介于两者之间，就像我们经常见到的技术演进一样。

ARM64让某些应用的计算速度快了一些，大多数应用占用的内存变得更多，也让一些编程技巧更容易使用。不过从总体上看，还不算重大变化。

在向64位过渡的过程中，ARM架构增加了寄存器的数量，并对其使用做了修改。改进了指令集，令其性能优于过去的32位处理器。

苹果也从这种过渡中改变自己。最大的变化是内联引用计数，这一改变使得在通常情况下，无需进行代价昂贵的哈希表查找，让对象的创建和销毁代价都减少了近一半。标签指针也有利于性能提升并减少了内存占用。

ARM64使苹果的硬件如虎添翼，尽管我们都知道这一天迟早会到来，但没想到这么快，真是很棒！

本文作者Mike Ash是Plausible Labs的软件工程师，同时也是一名滑翔机驾驶员，感谢Mike对本文的授权。原文链接：http://www.mikeash.com/pyblog /friday-qa-2013-09-27-arm64-and-you.html