本文简单汇总MESI和MOESI协议理解。

# MESI
* M： Modified

在当前CPU上是属于被修改过的，其他CPU尚未同步，内存的值已经过时

* E：Exclusive

独占的，其他CPU尚未同步，内存的值和当前独占的这份相同，如果其他CPU在bus上发 snooping，则同步给其他CPU，自己转成 Shared

* S：Shared

和其他CPU上的内容共享，并且内存的值和当前CPU已经其他CPU上的cache值一致

* I：Invalid

无效的，自己这份cache已经无效了，snooping自动会更新


MESI的状态机如下：
1. 自己的cache更新状态机

![image.png](/static/img/4f0a1ef7fc394566b1d590d3a5a678e6.image.webp)

2. snooping下的cache更新状态机

![image.png](/static/img/90f8cecfbfbc9860ea47544da0d7ba4a.image.webp)

arm上有几个bit来查看cache状态，如下

![image.png](/static/img/2f6313d3407c69ced696b488e1c3a156.image.webp)

# MOESI
相比于MESI多了个O，是从S状态的一种分化，O指的是Owner。所以S和O的概念会有刷新
* O：Owner

和Share类似，其他CPU上也是共享的，但是这份数据的Owner是当前CPU的cache，与Share不一样的是，O标志的更新，所以内存的值可能是旧的

* S：Shared

完全的共享状态，所以CPU都是当前这份内容，内存中的值是否是cache的值看snooping的情况

1. 自己的cache更新状态机

![image.png](/static/img/6fd8da813ef7cd9c184ff3e455f64cf5.image.webp)

2. snooping下的cache更新状态机

![image.png](/static/img/71a7ec92c43361f0e160cc9e0a20d6e9.image.webp)

arm上有几个bit来查看cache状态，如下

![image.png](/static/img/5feded5a202915e104a79947b94fd3ec.image.webp)

# 参考
> https://en.wikipedia.org/wiki/MESI_protocol
> https://en.wikipedia.org/wiki/MOESI_protocol

MESI和MOESI协议简介

cacheline导致的bug可以参考《不可忽视的cacheline问题》，本文介绍一个不是属于运行错误的例子，其属于性能损失，cache的伪共享，这类问题比cacheline导致的bug而言更容易出现，也是必须要解决的。

# False sharing
简单来说就是MESI和MOESI协议下，如果一个数据反复的在访问同一个cacheline，那么MOESI就会对bus上的数据进行invalidate，并在bus上进行snooping到每个CPU上。这种行为对于CPU的视角来看是低效的。相当于无意义的吃掉了内存的带宽，浪费了系统资源。

# 测试代码
测试代码来自参考里面，如下
```
#include <iostream>
#include <thread>
#include <new>
#include <atomic>
#include <chrono>
#include <latch>
#include <vector>

using namespace std;
using namespace chrono;

#if defined(__cpp_lib_hardware_interference_size)
// default cacheline size from runtime
constexpr size_t CL_SIZE = hardware_constructive_interference_size;
#else
// most common cacheline size otherwise
constexpr size_t CL_SIZE = 64;
#endif

int main()
{
    vector<jthread> threads;
    int hc = jthread::hardware_concurrency();
    hc = hc <= CL_SIZE ? hc : CL_SIZE;
    for (int nThreads = 1; nThreads <= hc; ++nThreads)
    {
        // synchronize beginning of threads coarse on kernel level
        latch coarseSync(nThreads);
        // fine synch via atomic in userspace
        atomic_uint fineSync(nThreads);
        // as much chars as would fit into a cacheline
        struct alignas(CL_SIZE) { char shareds[CL_SIZE]; } cacheLine;
        // sum of all threads execution times
        atomic_int64_t nsSum(0);
        for (int t = 0; t != nThreads; ++t)
            threads.emplace_back(
                [&](char volatile &c)
                {
                    coarseSync.arrive_and_wait(); // synch beginning of thread execution on kernel-level
                    if (fineSync.fetch_sub(1, memory_order::relaxed) != 1) // fine-synch on user-level
                        while (fineSync.load(memory_order::relaxed));
                    auto start = high_resolution_clock::now();
                    for (size_t r = 10'000'000; r--;)
                        c = c + 1;
                    nsSum += duration_cast<nanoseconds>(high_resolution_clock::now() - start).count();
                }, ref(cacheLine.shareds[t]));
        threads.resize(0); // join all threads
        cout << nThreads << ": " << (int)(nsSum / (1.0e7 * nThreads) + 0.5) << endl;
    }
}
```
其思路就是构造一个cacheline大小的数组
```
struct alignas(CL_SIZE) { char shareds[CL_SIZE]; } cacheLine;
```
然后对齐自加
```
            threads.emplace_back(
                [&](char volatile &c)
                {
                    for (size_t r = 10'000'000; r--;)
                        c = c + 1;
                }, ref(cacheLine.shareds[t]));
```
通过不断的增加线程来查看伪共享的负面效果
```
 for (int nThreads = 1; nThreads <= hc; ++nThreads)
```
# 测试
编译运行
```
g++ -std=c++20 falsesharing.cpp -o falsesharing
```
运行
```
# ./falsesharing
1: 3
2: 7
3: 12
4: 13
5: 14
6: 19
7: 21
8: 29
9: 30
10: 34
11: 37
12: 39
13: 41
14: 47
15: 49
16: 54
```
可以看到，随着多线程的加剧，这种伪共享带来的性能损失来到了 54 / 3 = 18倍。

# 如何解决
官方的解决方案如下：
1. 重新排序变量或在变量之间添加填充（未使用的字节）来防止 CPU 缓存中的虚假共享
2. 编译时数据转换还可以减少虚假共享

其实最简单直接的办法就是每个线程使用不同的数据，这样就规避了多个线程访问同一个cacheline的问题。
按照我的思路，直接让所有线程访问不同的cacheline，运行结果如下
```
# ./fixfalsesharing
1: 3
2: 3
3: 3
4: 3
5: 3
6: 2
7: 4
8: 3
9: 3
10: 3
11: 3
12: 3
13: 3
14: 3
15: 3
16: 3
```
# 总结
在编写多线程或者并发程序的时候，相比于cachelinebug《不可忽视的cacheline问题》，伪共享其实是更容易遇到和需要避免的问题，只要编程时有这样的印象，只需要很简单的让多线程不竞争同一个cacheline即可。
# 参考
> https://en.wikipedia.org/wiki/False_sharing



伪共享问题

现代CPU通常通过cache来加速内存的访问效果，例如arm 的MESI协议，但是我们不能轻易的忽视cacheline导致的代码问题。本文介绍一下cacheline导致的代码问题。
# 原理
arm系列cpu的cacheline通常是64字节，如果结构体的数据跨cacheline，MESI协议只能够有效的从Poc和Pou视角保证变量的一致性。跨cacheline的那个数据成员其实并没办法很好的保证其值在每时每刻的正确性。参考：《cache的策略》，但是这种跨cacheline的行为（跨CPU）还是有可能出现数据和理论情况不一致的情况。

为了构造上面的问题，我需要构造一个60字节+8字节的结构体，如下
```
#pragma pack(1)
struct data {
    int32_t pad[15];
    int64_t v;
};
static struct data value __attribute__((aligned(64)));
```
这种情况下，pad默认填充了cacheline的前60字节，而v变量正好处于cacheline的前4字节和后4字节

为了构造cacheline导致的数据异常的案例，我还需要将其放在线程里面运行，这样data结构体的实例化必须是全局的。

注意：这里 pack(1) 是强制按照1字节对齐，通过aligned(64)保证了value结构体一直在cacheline的开头

到这里基本上我的用意很明显了，我需要有一个线程运行函数，如下
```
static void worker(int *cnt) {
    for (int64_t i = 0; i < loop_count; ++i) {
        const int64_t t = value.v;

        *cnt += 1;

        value.v = ~t;
        __asm__ volatile("" ::: "memory");
    }
}
```
值得注意的是，为了避免编译器给我指令重排，我需要为其添加内存栅栏
```
__asm__ volatile("" ::: "memory");
```
这里的输入部和输出部都是空，所以此汇编只是简单的声明内存栅栏


# 运行
测试程序需要两个输入参数，一个是线程的个数，为了让这个任务在多个CPU上运行，另一个是线程将value.v反转的次数。
```
    int64_t n = min(atol(argv[1]), N_THREADS);
    loop_count = atol(argv[2]);
```

根据worker函数是一个非常简单的逻辑，就是简单的将value.v不断反转。这个代码运行理论上的值应该是
```
FFFFFFFFFFFFFFFF
0000000000000000
```

那实际上呢？ 我们运行看看
```
# ./cacheline_bug 8 10000
iteration: 80000
data size: 68
final: FFFFFFFFFFFFFFFF
# ./cacheline_bug 8 10000
iteration: 80000
data size: 68
final: 0000000000000000
# ./cacheline_bug 8 10000
iteration: 80000
data size: 68
final: 00000000FFFFFFFF
# ./cacheline_bug 8 10000
iteration: 80000
data size: 68
final: FFFFFFFF00000000
```
可以看到，v的值有四种情况，这里
```
00000000FFFFFFFF
FFFFFFFF00000000
```
就是cache带来的隐藏问题。
# 总结
在开发高性能的程序的时候，一方面需要利用好cache的特性，另一方面在存在数据竞争的场景下也需要考虑周全，否则就容易出现cache带来的隐藏bug。

# 源码
下面分享一下测试的源码，本文分享基于arm V8 上运行
```
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

#ifndef min
#define min(x, y) (x) < (y) ? (x) : (y)
#endif

#define N_THREADS 128
static int64_t loop_count = 0;

#pragma pack(1)
struct data {
    int32_t pad[15];
    int64_t v;
};

static struct data value __attribute__((aligned(64)));
static int64_t counter[N_THREADS];

static void worker(int *cnt) {
    for (int64_t i = 0; i < loop_count; ++i) {
        const int64_t t = value.v;
        *cnt += 1;

        value.v = ~t;
        /* creates a compiler level memory barrier
         * forcing optimizer to not re-order memory
         * accesses across the barrier. */
        __asm__ volatile("" ::: "memory");
    }
}

int main(int argc, char *argv[]) {
    pthread_t threads[N_THREADS];

    if (argc != 3) {
        fprintf(stderr, "USAGE: %s <threads> <loopcount>\n", argv[0]);
        return 1;
    }

    int64_t n = min(atol(argv[1]), N_THREADS);
    loop_count = atol(argv[2]);

    for (int64_t i = 0L; i < n; ++i)
        pthread_create(&threads[i], NULL, (void *(*) (void *) ) worker,
                       &counter[i]);

    int64_t count = 0L;
    for (int64_t i = 0L; i < n; ++i) {
        pthread_join(threads[i], NULL);
        count += counter[i];
    }

    printf("iteration: %lu\n", count);
    printf("data size: %lu\n", sizeof(value));
    printf("final: %016lX\n", value.v);

    return 0;
}
```
















不可忽视的cacheline问题

编写高性能的C程序的时候经常需要设计状态机，通过设计状态机可以完成复杂系统的业务逻辑编程实现，状态机可以管理状态和转换，使代码更容易理解和维护，不过很多时候，大家编写的状态机程序都存在一些性能问题，本文聚焦高性能C语言状态机的实现进行说明
# 什么是状态机
状态机也称有限状态机（Finite State Machine, FSM），其最初是一种数学模型，用于描述系统在不同状态之间根据输入进行转换的行为。

假设需要设计一个开关灯的程序，可以通过如下方式来说明状态机
```
        +------------------+
        |                  |
        v      Toggle      |
     +------+          +------+
     | Off  | -------->| On   |
     +------+ <--------+------+
        ^                  |
        |      Toggle     |
        +------------------+
```
根据上面这个最简单的状态机可以总结如下几个必要的要素
* 状态集和： off/on
* 初始状态： off
* 输入： toggle
* 状态转移： off->on

针对这些必要条件，下面列出高性能状态机的几个细节，基于C语言
# 通过枚举实现状态集和
高性能的状态机的必要添加之一就是枚举，通过枚举来实现状态集和相比于代码中的幻数而言是最轻松最容易管理的。
一个简单的状态集和可以如下
```
typedef enum {
    STATE_INIT,
    STATE_RUNNING,
    STATE_STOPPED,
    STATE_ERROR
} State;

State currentState = STATE_INIT;
```
# 高效的状态转移
大部分不关注性能的状态机喜欢使用if来进行判断，例如
```
if(state == STATE_INIT) {
   # TODO
} else if(state == STATE_RUNNING) {
   # TODO
}
```
但是if通常对于cpu的预测而言并不友好，这样在处理状态转换时候会有极大性能损失。可以考虑使用switch-case结构。这种方法通常更快更高效。编译器在处理switch语句上具有最高的性能
```
void handleState(State state) {
    switch (state) {
        case STATE_INIT:
            // Initialization logic
            break;
        case STATE_RUNNING:
            // Running logic
            break;
        case STATE_STOPPED:
            // Stopped logic
            break;
        case STATE_ERROR:
            // Error handling
            break;
        default:
            // Handle unexpected state
            break;
    }
}
```
额外信息：有兴趣的可以了解 达夫设备：https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Duffs-Device.html
# 更高效的状态转移
switch已经满足绝大部分情况下的状态转移，如果追求极高的性能，可以直接避免编译器做任何的分支预测，直接使用函数指针代替分支预测形式的语法。例如
```
void initState() {
    // Initialization logic
}

void runningState() {
    // Running logic
}

void stoppedState() {
    // Stopped logic
}

void errorState() {
    // Error handling
}

void (*stateHandlers[])() = {
    initState,
    runningState,
    stoppedState,
    errorState
};

void handleState(State state) {
    stateHandlers[state]();
}
```
通过 `handleState`函数直接调用函数指针，代码在运行的时候，直接可以通过state的局部变量参数进行函数指针的偏移，从而直接定位到确定的函数调用上。

不过需要注意的是，绝大部分情况下，switch-case已经是最高效的状态机设计方案了。如果状态机状态集和过多，函数指针的优势才能体现。所以选择switch-case还是函数指针并没有什么约束，看个人爱好
# 最小化状态转移
状态机内部的状态转移经常容易出现重复状态的转移，这种很容易变成不轻易被发现的性能问题，当任务从`STATE_RUNNING`切换到`STATE_RUNNING`时，状态转移函数应该准确的识别，避免不必要的性能消耗，如下
```
void transitionTo(State newState) {
    if (currentState != newState) {
        currentState = newState;
        // Additional logic for state change
    }
}
```
# 极致内存占用
状态集和的状态，尽可能的时候位处理的方式实现，通过一个整数来表达多个状态，是内存友好型的行为。linux内核经常这么使用，如下
```
#define STATE_INIT    (1 << 0)
#define STATE_RUNNING (1 << 1)
#define STATE_STOPPED (1 << 2)
#define STATE_ERROR   (1 << 3)

int currentStateFlags = 0;

void setState(int state) {
    currentStateFlags |= state;
}

void clearState(int state) {
    currentStateFlags &= ~state;
}

bool isStateActive(int state) {
    return (currentStateFlags & state) != 0;
}
```
# 禁用动态内存
使用动态内存申请的方式获取数据结构会导致任务的高性能依赖操作系统的内存管理，如果需要开发极高性能的程序状态机，此时建议直接禁止动态内存申请。全部改用静态内存分配。

通过静态分配内存，可以有效的避免动态分配的开销和抖动。

但是另一方面又需要注意的是，一些非状态机外的场景，使用动态内存可以有效的节省内存使用。此情况额外分析。这里只谈涉及高性能状态机内的场景
```
typedef struct {
    State state;
    // Other state-related data
} StateMachine;

StateMachine sm = {STATE_INIT};
```
# 总结
通过使用枚举、优化过渡逻辑、利用函数指针、最小化状态变化以及有效管理内存，可以显著提升状态机的性能。

如果自己在编写状态机时需要抄作业，下面提供了一个开源的高效状态机的仓库，可以直接搬运。
> https://github.com/endurodave/C_StateMachine






高性能C的状态机优化

Arm默认提供硬件crc的指令集，这样在操作系统上的很多校验操作都可以使用crc指令完成，它对于高性能程序开发和校验来说不可或缺。例如网络，媒体，存储，文件系统等等。
# crc是什么
循环冗余校验(Cyclic Redundancy Check)可以检查数据是否出现意外错误。它将一串数据看作一个二进制多项式，然后用一个预定义的“生成多项式”去除它，得到的余数就是 CRC 的校验值。

如果通过软件crc完成，那么cpu会突然暴涨，而arm cpu默认就带crc的硬件功能，我们直接使用就行。

我们在例如操纵系统打包，内存冗余校验都可以用crc完成。
# 查询crc功能
内核cpuinfo就能查询crc32的功能，如下
```
root@ubuntu:~# cat /proc/cpuinfo | grep crc32
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp uscat ilrcpc flagm paca pacg
```
编译器已经默认打开crc32的选项，无需重新构建编译器
```
armv8-a+crc
```
# 验证完整性
例如操作系统校验，我们可以取系统镜像的前1M，后面随机再取1M进行crc校验，这样能够有效的在不浪费内存加载的前提上进程完整性校验。所以直接提供api实现即可。

软件实现如下
```
static uint32_t crc32_software(const uint8_t *data, size_t len)
{
    uint32_t crc = 0xFFFFFFFFU;
    for (size_t i = 0; i < len; ++i) {
        crc = crc32_table[(crc ^ data[i]) & 0xFF] ^ (crc >> 8);
    }
    return crc ^ 0xFFFFFFFFU;
}
```
硬件实现如下
```
static uint32_t crc32_hardware(const uint8_t *buf, size_t len)
{
    uint32_t crc = 0xFFFFFFFFU;

    while (len >= 8) {
        uint64_t v = *(const uint64_t *)buf;
        crc = __crc32d(crc, v);
        buf += 8;
        len -= 8;
    }

    while (len--) {
        crc = __crc32b(crc, *buf++);
    }

    return crc ^ 0xFFFFFFFFU;
}
```
对应的查表如下
```
static const uint32_t crc32_table[256] = {
    0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
    0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91,
    0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE, 0x1ADAD47D, 0x6DDDE4EB, 0xF4D4B551, 0x83D385C7,
    0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC, 0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5,
    0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172, 0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B,
    0x35B5A8FA, 0x42B2986C, 0xDBBBC9D6, 0xACBCF940, 0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59,
    0x26D930AC, 0x51DE003A, 0xC8D75180, 0xBFD06116, 0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
    0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924, 0x2F6F7C87, 0x58684C11, 0xC1611DAB, 0xB6662D3D,
    0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A, 0x71B18589, 0x06B6B51F, 0x9FBFE4A5, 0xE8B8D433,
    0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818, 0x7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01,
    0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E, 0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457,
    0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA, 0xFCB9887C, 0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65,
    0x4DB26158, 0x3AB551CE, 0xA3BC0074, 0xD4BB30E2, 0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB,
    0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0, 0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
    0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2086, 0x5768B525, 0x206F85B3, 0xB966D409, 0xCE61E49F,
    0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4, 0x59B33D17, 0x2EB40D81, 0xB7BD5C3B, 0xC0BA6CAD,
    0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A, 0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683,
    0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8, 0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1,
    0xF00F9344, 0x8708A3D2, 0x1E01F268, 0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7,
    0xFED41B76, 0x89D32BE0, 0x10DA7A5A, 0x67DD4ACC, 0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5,
    0xD6D6A3E8, 0xA1D1937E, 0x38D8C2C4, 0x4FDFF252, 0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
    0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60, 0xDF60EFC3, 0xA867DF55, 0x316E8EEF, 0x4669BE79,
    0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 0xCC0C7795, 0xBB0B4703, 0x220216B9, 0x5505262F,
    0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 0xC2D7FFA7, 0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D,
    0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A, 0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713,
    0x95BF4A82, 0xE2B87A14, 0x7BB12BAE, 0x0CB61B38, 0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21,
    0x86D3D2D4, 0xF1D4E242, 0x68DDB3F8, 0x1FDA836E, 0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777,
    0x88085AE6, 0xFF0F6A70, 0x66063BCA, 0x11010B5C, 0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
    0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D, 0x3E6E77DB,
    0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0, 0xA9BCAE53, 0xDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9,
    0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6, 0xBAD03605, 0xCDD70693, 0x54DE5729, 0x23D967BF,
    0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94, 0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D
};
```
这样直接调用函数crc32_software或crc32_hardware即可。
# 测试
为了满足测试要求，可以编写测试程序验证，并编译，编译如下
```
gcc -O3 -march=armv8-a+crc -o test test.c
```
以测试操作系统完整性为例，为了方便测试，这里直接加载全部操作系统，当然，也可以选择部分片段来做完整性校验
```
# ls -lh rootfs.img
-rw-r--r-- 1 root root 2.0G 12月  8 23:26 rootfs.img
# ./test rootfs.img
Software  : 8.740870 s  →  0.23 GB/s   CRC32 = 0xfd94b9a9
Hardware  : 0.236808 s  →  8.45 GB/s   CRC32 = 0xfd94b9a9
Speedup   : 36.9x
Verify    : PASS
```
可以看到，相比于软件crc校验，crc计算的时间提高了36.9倍。
# 测试代码
如下是测试代码，可以直接使用
```
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <time.h>
#include <arm_acle.h>

#define ITERATIONS 10

static const uint32_t crc32_table[256] = {
    0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA, 0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
    0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988, 0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91,
    0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE, 0x1ADAD47D, 0x6DDDE4EB, 0xF4D4B551, 0x83D385C7,
    0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC, 0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5,
    0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172, 0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B,
    0x35B5A8FA, 0x42B2986C, 0xDBBBC9D6, 0xACBCF940, 0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59,
    0x26D930AC, 0x51DE003A, 0xC8D75180, 0xBFD06116, 0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
    0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924, 0x2F6F7C87, 0x58684C11, 0xC1611DAB, 0xB6662D3D,
    0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A, 0x71B18589, 0x06B6B51F, 0x9FBFE4A5, 0xE8B8D433,
    0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818, 0x7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01,
    0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E, 0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457,
    0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA, 0xFCB9887C, 0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65,
    0x4DB26158, 0x3AB551CE, 0xA3BC0074, 0xD4BB30E2, 0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB,
    0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0, 0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
    0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2086, 0x5768B525, 0x206F85B3, 0xB966D409, 0xCE61E49F,
    0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4, 0x59B33D17, 0x2EB40D81, 0xB7BD5C3B, 0xC0BA6CAD,
    0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A, 0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683,
    0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8, 0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1,
    0xF00F9344, 0x8708A3D2, 0x1E01F268, 0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7,
    0xFED41B76, 0x89D32BE0, 0x10DA7A5A, 0x67DD4ACC, 0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5,
    0xD6D6A3E8, 0xA1D1937E, 0x38D8C2C4, 0x4FDFF252, 0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
    0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60, 0xDF60EFC3, 0xA867DF55, 0x316E8EEF, 0x4669BE79,
    0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 0xCC0C7795, 0xBB0B4703, 0x220216B9, 0x5505262F,
    0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 0xC2D7FFA7, 0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D,
    0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A, 0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713,
    0x95BF4A82, 0xE2B87A14, 0x7BB12BAE, 0x0CB61B38, 0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21,
    0x86D3D2D4, 0xF1D4E242, 0x68DDB3F8, 0x1FDA836E, 0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777,
    0x88085AE6, 0xFF0F6A70, 0x66063BCA, 0x11010B5C, 0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
    0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D, 0x3E6E77DB,
    0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0, 0xA9BCAE53, 0xDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9,
    0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6, 0xBAD03605, 0xCDD70693, 0x54DE5729, 0x23D967BF,
    0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94, 0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D
};

static uint32_t crc32_software(const uint8_t *data, size_t len)
{
    uint32_t crc = 0xFFFFFFFFU;
    for (size_t i = 0; i < len; ++i) {
        crc = crc32_table[(crc ^ data[i]) & 0xFF] ^ (crc >> 8);
    }
    return crc ^ 0xFFFFFFFFU;
}

static uint32_t crc32_hardware(const uint8_t *buf, size_t len)
{
    uint32_t crc = 0xFFFFFFFFU;

    while (len >= 8) {
        uint64_t v = *(const uint64_t *)buf;
        crc = __crc32d(crc, v);
        buf += 8;
        len -= 8;
    }

    while (len--) {
        crc = __crc32b(crc, *buf++);
    }

    return crc ^ 0xFFFFFFFFU;
}

static uint64_t get_ns(void)
{
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}

int main(int argc, char **argv)
{
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <file>\n", argv[0]);
        return 1;
    }

    const char *path = argv[1];

    int fd = open(path, O_RDONLY);
    if (fd == -1) { perror("open"); return 1; }

    struct stat st;
    if (fstat(fd, &st) == -1) { perror("fstat"); close(fd); return 1; }
    off_t filesize = st.st_size;
    if (filesize == 0) {
        printf("File is empty\n");
        close(fd);
        return 0;
    }

    void *map = mmap(NULL, filesize, PROT_READ, MAP_PRIVATE, fd, 0);
    if (map == MAP_FAILED) { perror("mmap"); close(fd); return 1; }
    close(fd);

    const uint8_t *data = (const uint8_t *)map;

    crc32_software(data, filesize);
    crc32_hardware(data, filesize);

    uint64_t best_sw = -1ULL, best_hw = -1ULL;
    uint32_t crc_sw = 0, crc_hw = 0;

    for (int i = 0; i < ITERATIONS; ++i) {
        uint64_t t0 = get_ns();
        crc_sw = crc32_software(data, filesize);
        uint64_t t1 = get_ns();
        uint64_t dt = t1 - t0;
        if (dt < best_sw) best_sw = dt;
    }

    for (int i = 0; i < ITERATIONS; ++i) {
        uint64_t t0 = get_ns();
        crc_hw = crc32_hardware(data, filesize);
        uint64_t t1 = get_ns();
        uint64_t dt = t1 - t0;
        if (dt < best_hw) best_hw = dt;
    }

    double sec_sw = best_sw * 1e-9;
    double sec_hw = best_hw * 1e-9;
    double gb_sw  = filesize / (sec_sw * 1073741824.0);
    double gb_hw  = filesize / (sec_hw * 1073741824.0);

    printf("Software  : %.6f s  →  %.2f GB/s   CRC32 = 0x%08x\n", sec_sw, gb_sw, crc_sw);
    printf("Hardware  : %.6f s  →  %.2f GB/s   CRC32 = 0x%08x\n", sec_hw, gb_hw, crc_hw);
    printf("Speedup   : %.1fx\n", sec_sw / sec_hw);
    printf("Verify    : %s\n", (crc_sw == crc_hw) ? "PASS" : "FAIL");

    munmap(map, filesize);
    return 0;
}

```








