/* There are multiple approaches to calculate crc.
Approach-1: Process 8 bytes then 4 bytes then 2 bytes and then 1 bytes
Approach-2: Process 8 bytes and remaining workload using 1 bytes
Apporach-3: Process 64 bytes at once by issuing 8 crc call and remaining
using 8/1 combination.
Based on micro-benchmark testing we found that Approach-2 works best especially
given small chunk of variable data. */
作者: bzhaoopenstack
2020年是非常令人难忘的一年，2020年是我们包含的无数个首次，居家隔离，在家办公，千辛万苦从老家赶往单位上班，从艰难的上班路程一直到现在越来越趋于正常的环境。回想这一整年，我们从今年年后开始组建团队在社区上游进行鲲鹏优化相关的工作，一开始我们只有两个人，到现在的初具规模，伙伴们从一个ARM优化小白成长到能够独挡一面的先驱者，这一年的经历相信会在我们的人生当中留下浓重的一笔。
就在昨天，通过组内的不懈努力，我们在MariaDB开源社区上游获得社区官方的认可，团队中的大佬Krunal Bauskar榜上有名，同时还有来自ARM公司的Gu Yuqi和AWS的Tsahi Zidenberg。这是社区对我们的承认，感谢社区，期望我们今后能够为越来越多的幕后英雄鼓掌。
我们浏览一下来自MariaDB Foundation的Vicențiu Ciorbaru在信中描述的，原文参见这里:
在2020年， 各行各业有很多ARM架构的声音。对于MariaDB来说，情况也是一样的。首先，在今年，我们已经扩展了测试基础架构，用以在ARM上的覆盖更多Linux发行版（Debian,Ubuntu,Fedora,CentOS,RedHat），我们正在为所有这些Linux发行版构建MariaDB软件包。除了现有的RPM和DEB包之外，下一个MariaDB发行版的tar包还将包括可在ARM上运行的二进制文件。
所有的这些都离不开华为的帮助，华为已经给我们捐赠几台ARM构建机器用于扩展测试基础架构来满足这项工作的需求。我们坚信，只有通过在尽可能多平台上进行测试，使用尽可能多的编译器，我们才能保证MariaDB的高性能和稳定性。旁注，社区仍然缺少SPARC硬件，如果您碰巧有可用的硬件，请告诉我们。
此外，我们还要感谢Krunal Bauskar, Gu Yuqi 和Tsahi Zidenberg为我们增强了ARM的性能和相关错误的修复。
为了获得最佳性能，编写代码时应考虑到底层硬件。这就是为什么性能关键代码尽可能使用本机指令的原因。这种情况就是计算crc32c校验和，由Gu Yuqi通过PR 772贡献。Krunal在此工作上引入了PR 1558，其中统一了crc32库，并尽可能使用SIMD（单指令，多数据）包装器来确保运行高效。此外，某些任务，如检测代码或计时相关的函数调用，需要非常精确的计时器。通过添加本机ARM代码，my_timer_cycles()引入了精确的硬件计时器。这是通过PR 1620实现的，与此同时还能通过编译器标志来改进原子操作性能。
我们感谢社区参与确保MariaDB利用所有可用的硬件功能，我们期待获得更多！
谢谢！
相当振奋啊，不过我们的文风不应该是纯粹的吹捧，干货还是要的。下面我们分析一下，信中提及的MariaDB在ARM上的硬件优化。
PR 772这个PR比较好的阐释了如何将一个底层硬件功能开放到上层软件，代码结构非常清晰。从crc32.cmake自适应底层架构进行分支选择，使用ARM v8加密指令优化crc32c计算密集型任务，放弃使用原本的线性crc指令，提升CPU的稳定性。引入了新的extension, 位置在extra/crc32_armv8_neon/crc32_armv8.c，都是底层汇编的适配。x86使用的是crc32b和crc32q汇编指令完成CRC32C校验值计算功能，而Arm64平台使用crc32cb、crc32ch、crc32cw、crc32cx 4个汇编指令完成CRC32C校验值计算功能。
更多的请参考官方文档，或者这里
PR 1558这个PR是基于PR 772进行的改进，引入位于mysys/checksum.c的上层接口，用于计算表和binlog校验和。并对powerpc，X86和ARM平台都进行了优化，X86使用的是PCLMUL指令，ARM使用ACLE调用底层指令替代了默认的zlib-crc32。同时对相关checksum使用的调用进行了规整，梳理出了对应所有硬件平台的内部上层接口，包含x86, ARM, POWERPC等等硬件平台，使其尽量使用底层硬件加速，避免回退到zlib crc32软实现。回看这里，对于ARM，亮点不但是使用了底层加速，还是基于SIMD思想的。那么，
What is SIMD？
通常我们进行多媒体处理的时候,很多的数据都是16位或者8位的,如果这些程序运行在32位的机器上,那么计算机有一部分的计算单元是没有工作的.所以这是一种浪费.为了更好的使用那些被浪费的资源.SIMD就应运而生了.SIMD这种技术就是使用一条指令，但对多个相同类型和尺寸的数据进行并行处理.就像我们现实生活中的好几个人都在做同一件事情那样,这样就可以将速度提升很多倍.
这个PR干了啥？看extra/crc32_armv8_neon/crc32_armv8.c
充分测试后，上述第二种的性能最高，特别是在小块数据的场景中，好底层啊，算法和原理参考这里，同时测出来的数据就是这么表现的。看着其实就是运算时合理利用闲置的硬件资源，尽量保证使用更多的硬件，ARM的有效性体现的淋漓尽致，估计后面的优化工作会有大量相关的代码优化。
然后，我抱着试试看的态度，将这两个PR进行了测试，结果还是比较喜人的。
你发现了什么？我们发现了合入后checksum时间由15秒降到了7.4秒，近50%性能提升！
PR 1620引入了两个东西，一个是引入了gcc
-moutline-atomics能让应用自定义原子操作，另外将硬件时钟引入到mysql/innodb自己的时钟周期，这样，让程序代码执行时间的衡量可以精确到CPU Cycle级别，是不是有种合二为一的感觉。其实这类具体的做法比较早的就有人发出来了，可以参考这里,这一点说明软件可以更贴近硬件来做优化。总的来说，硬件适配及底层硬件功能应用在ARM上也才刚刚起步，尤其是在开源社区上游，我们要做的工作还有很多，但是目前来看，ARM的潮流已经来了，苹果的M1，以及最近微软宣称自己也要开始研发自己的ARM芯片，这说明ARM的圈子慢慢变大，从最开始的ARM，到ARM + 华为 + AWS，到现在广大的群体。其实作为云厂商的AWS给我们上了非常重要的一课，排老大到底是有原因的，作为未来厂商的发展，一定是软硬结合的这种结构，所以软件生态牵引硬件这种模式应该会持续很久。
好了，ARM是否能独闯一片天地，现在的趋势说明了一切，对于鲲鹏来说，我觉得是非常好的势头，让我们拭目以待吧。