文章转载于微信公众号:计算魔方
作者:赵波
不平凡的2020年马上就要结束了，又到了总结的季节。若要总结IT行业年度关键字，我相信"Arm"一定会榜上有名，因为每过一段时间，总会有与"Arm"相关的消息占据新闻头条。这不，又有关于Arm生态相关的好消息传来。在老牌开源数据库MariaDB社区于近日在其官方博客总结了2020年MariaDB在Arm支持和性能优化方面取得的最新进展(https://mariadb.org/arm-impro...，我们这里带着读者一起看一下这篇博文，并简单展开一下博文中提到的一些技术细节。请点击阅读原文查看博客原文。
01基础设施与软件包
得益于新增的Arm架构基础设施资源，MariaDB社区目前在几款主流Linux发行版(包括Debian, Ubuntu, Fedora, CentOS, RedHat)上都进行了完整的测试和集成验证，并且在这些OS上都进行了软件包的发布。同时，从下个版本开始，MariaDB社区将会发布Arm架构的binary tarballs，以便满足更多用户的需求。
在博文中，MariaDB社区也再次对华为提供的大量Arm架构基础设施资源进行了感谢。当前华为共为MariaDB社区提供了4台鲲鹏云服务器作为测试基础设施，并同时提供了专职工程师配合MariaDB社区进行相应的维护工作，确保MariaDB在Arm平台的开发流程稳定。
02软硬件协同，释放算力
除了测试基础设施外，来自Arm、华为等公司的开发者也为MariaDB带来了多个有针对性的优化和修复、使得MariaDB在Arm上的稳定性和性能得到了大幅提升。
通过软硬件协同来充分释放硬件算力，是最为常见的性能提升手段，Arm平台上的性能优化自然也遵循这个规律。接下来让我们看看MariaDB在2020年是如何充分发挥Arm平台的算力的。
01crc32硬件加速
crc32(32位循环冗余校验)是一种最为常用的数据检错手段，在MariaDB的多种使用场景，都有对crc32的使用。ARMv8 (AArch64) CPU的扩展指令集版本ARMv8.1中包含了对crc32进行硬件加速的支持。因此，如果能在计算时使用crc32硬件加速，则可以很大程度的提升计算性能。
来自Arm公司的Yuqi Gu(Github: https://github.com/guyuqi)，通过PR-772(https://github.com/MariaDB/se...。这个PR很好的阐释了如何将一个底层硬件功能开放到上层软件，代码结构非常清晰。从crc32.cmake自适应底层架构进行分支选择，使用ARM v8.1扩展指令集优化crc32c计算密集型任务，提升CPU的稳定性。
与其他平台对比来看x86使用的是crc32b和crc32q汇编指令完成CRC32C校验值计算功能，而Arm64平台使用crc32cb、crc32ch、crc32cw、crc32cx 4个汇编指令完成CRC32C校验值计算功能。这几个指令的区别如下：
更详细的内容请参考官方指南或鲲鹏社区迁移指南(https://support.huaweicloud.c...。
来自华为的Krunal Bauskar在PR-772的基础上做了进一步改进，在PR-1558(https://github.com/MariaDB/se...，引入位于mysys/checksum.c的上层接口，用于计算表和binlog的校验和。还对X86和ARM都进行了优化，充分利用了SIMD，带来巨大的性能提升。X86使用的是PCLMUL指令，ARM使用ACLE调用底层crc32加速指令替代了默认的zlib-crc32。并对相关checksum使用的调用进行了规整，梳理出了对应所有硬件平台的内部上层接口，包含x86, ARM, POWERPC等等硬件平台，使其尽量使用底层硬件加速，避免回退到zlib crc32软实现。
在应用了上述的优化后，我们也做了一个简单的性能对比：
优化前：
mysql> checksum table test.sbtest1;
+--------------+------------+
| Table | Checksum |
+--------------+------------+
| test.sbtest1 | 3664919850 |
+--------------+------------+
1 row in set (15.06 sec)
mysql> checksum table test.sbtest2;
+--------------+------------+
| Table | Checksum |
+--------------+------------+
| test.sbtest2 | 2870489758 |
+--------------+------------+
1 row in set (15.07 sec)优化后：
mysql> checksum table test.sbtest1;
+--------------+------------+
| Table | Checksum |
+--------------+------------+
| test.sbtest1 | 3664919850 |
+--------------+------------+
1 row in set (7.35 sec)
mysql> checksum table test.sbtest2;
+--------------+------------+
| Table | Checksum |
+--------------+------------+
| test.sbtest2 | 2870489758 |
+--------------+------------+
1 row in set (7.41 sec)可以很直观的看到，优化后checksum时间由15秒降到了7.4秒，近50%性能提升。
02原子操作&硬件时钟
来自Amazon的Tsahi Zidenberg在PR-1620(https://github.com/ MariaDB/server/pull/1620)中为MariaDB带来了另外两个非常重要的Arm平台优化。首先，他为MariaDB引入了-moutline-atomics的gcc编译选项，使得应用可以自定义原子操作，从而提升原子操作的性能。除此之外，他还为MariaDB带来了Arm架构下的精准硬件时钟：my_timer_cycles()；有了这个精准硬件时钟后，程序代码执行时间的衡量可以精确到CPU Cycle级别。这对于一些有高精确度要求的操作，比如对硬件指令的直接操作和其他队时间敏感性较高的操作来说，有很大的实际价值。
03自旋锁优化
除了MariaDB博客中提到的三个PR外，我们这里也再补充一个使用软硬件协同大幅度提升性能的例子。在我们往期的技术分享中，已经为大家介绍了自旋锁的相关内容。在MariaDB中，我们通过在ARM64平台添加执行内存屏障(__asm__ volatile ("":::"memory");)，防止编译优化，保持CPU空转（即不执行任何操作)大幅提升了相关流程的性能(约40%)，具体细节请回看相关推送。(相关Patch:
https://github.com/MariaDB/se...。
03小结
2020年，随着Arm平台在数据中心及桌面领域曝光度的不断增加，越来越多的开发者和用户都投入到Arm软件生态的发展中来。开源开放的各开源项目也为Arm生态的快速拓展提供了优质的土壤，随着各领域开源软件在Arm平台的不断完善和优化，相信会有越来越多的用户将Arm平台用在实际的生产活动中。也希望有更多的开发者能参与到Arm生态的拓展中来，一起让它变得更好。
