x32 ABI

kernel 3.4发布了,其中一个更新是加入对x32 ABI的支持。

与此前曾介绍的armel与armhf关系一样,x32并不是intel处理器的一种新架构,而是在intel 64位处理器上(也许将来也会用到ARM上?)的一种二进制程序调用规范。它的主要想法是:

在64位处理器上,所有的指针自然也应该是64位的,但很多应用程序在运行时并不需要超过4GB的内存,因此64位的指针是浪费的。这些浪费体现在程序大小上、程序运行后可执行代码占用的内存上,当然这些都是相对来说不必考虑的,但从CPU cache的角度考虑,64位的指针和32位的指针,对本来容量就很小的cache就意义重大了。从逻辑上,32位指针应该可以让cache缓存更多内容,并且在一致性维护上的开销更小。

但如果在64位CPU上纯粹地以兼容模式跑32位程序,又无法充分利用64位CPU的一些特性,例如更大的寄存器、更快的函数参数传递、更快的浮点运算、更快的syscall等。

因此,出现了x32这种折中。与armhf类似,它的改动也很简单:在x64 ABI基础上,将指针全部改为32位。

一份性能测试结果如下(完整介绍在这里):

On Core i7 2600K 3.40GHz:
Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over Intel64.
Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32.
Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against Intel64.
Comparing against ia32 PIC, x32 PIC:
Improved SPEC CPU 2K INT by another 10%.
Improved SPEC CPU 2K FP by another 3%.
Improved SPEC CPU 2006 INT by another 6%
Improved SPEC CPU 2006 FP by another 2%.

作为一种独立于编译工具和应用程序的通用优化方法,这种改进的效果可以说是非常显著而有价值的。

虽然说起来简单,但实际要做的工作并不少。因为这两种调用约定在二进制级别并不能兼容,从armel到armhf迁移的经验来看,需要的工作应该是:开发工具链、内核支持和迁移、公用代码库迁移、常用软件迁移等。这一次kernel的更新,应该是指第二步已经完成了。

linux社区在armhf和x32这两种新的ABI上的动作,给我两种感觉:从小的来说,随着编译优化的不断前进,以往忽略的ABI可能是性能的瓶颈,在这方面是否还有进一步修改优化的余地?从大的看,ABI这种已经形成实施标准的东西,居然也是可以迁移和并存的,考虑另一些领域,例如网络、例如总线,在广泛应用的事实标准存在的情况下,有没有可能出现新的更优方案?以往总认为代价太大而不值得,但现在这两件事提供了参考。

发表评论

电子邮件地址不会被公开。 必填项已用*标注