在 Ulrich Drepper 的论文中 What every programmer should know about memory ，第 3 部分:CPU 缓存，他展示了一张图表，显示“工作集”大小与每个操作消耗的 cpu 周期(在本例中为顺序读取)之间的关系。图中有两个跳转，表示一级缓存和二级缓存的大小。我编写了自己的程序来重现 c 中的效果。它只是简单地从头到尾依次读取一个 int[] 数组，我尝试了不同大小的数组(从 1KB 到 1MB)。我将数据绘制成图表，没有跳跃，图表是一条直线。

我的问题是:

1. 我的方法有问题吗？ cpu cache效果的正确方法是什么(看跳转)。
2. 我在想，如果是顺序读，那么应该是这样操作的: 当读取到第一个元素时，是cache miss，在cache line size(64K)内，会命中。在预取的帮助下，读取下一个缓存行的延迟将被隐藏。它会连续读取数据到一级缓存，即使工作集大小超过一级缓存大小，它也会驱逐最近最少使用的数据，并继续预取。因此大部分缓存未命中将被隐藏，从 L2 获取数据所消耗的时间将隐藏在读取 Activity 之后，这意味着它们是同时操作的。关联性(在我的例子中是 8 种方式)将隐藏从 L2 读取数据的延迟。那么，我的程序现象应该是正确的，我是不是漏掉了什么？
3. 是否有可能在 java 中获得相同的效果？

顺便说一下，我是在 linux 上做的。

编辑1

感谢 Stephen C 的建议，这里有一些额外的信息: 这是我的代码:

int *arrayInt;

void initInt(long len) {
    int i;
    arrayInt = (int *)malloc(len * sizeof(int));
    memset(arrayInt, 0, len * sizeof(int));
}

long sreadInt(long len) {   
    int sum = 0;
    struct timespec tsStart, tsEnd;

    initInt(len);

    clock_gettime(CLOCK_REALTIME, &tsStart);
    for(i = 0; i < len; i++) {
        sum += arrayInt[i];
    }
    clock_gettime(CLOCK_REALTIME, &tsEnd);
    free(arrayInt);
    return (tsEnd.tv_nsec - tsStart.tv_nsec) / len;
}

在 main() 函数中，我尝试了 1KB 到 100MB 的数组大小，仍然相同，每个元素的平均耗时为 2 纳秒。我认为时间是L1d的访问时间。

我的缓存大小:

L1d == 32k

L2 == 256k

L3 == 6144k

编辑2

我已经更改我的代码以使用链表。

// element type
struct l {
    struct l *n;
    long int pad[NPAD]; // the NPAD could be changed, in my case I set it to 1
};

struct l *array;
long globalSum;

// for init the array
void init(long len) {
    long i, j;

    struct l *ptr;

    array = (struct l*)malloc(sizeof(struct l));
    ptr = array;
    for(j = 0; j < NPAD; j++) {
        ptr->pad[j] = j;
    }
    ptr->n = NULL;

    for(i = 1; i < len; i++) {
        ptr->n = (struct l*)malloc(sizeof(struct l));
        ptr = ptr->n;
        for(j = 0; j < NPAD; j++) {
            ptr->pad[j] = i + j;
        }
        ptr->n = NULL;
    }

}

// for free the array when operation is done
void release() {
    struct l *ptr = array;
    struct l *tmp = NULL;
    while(ptr) {
        tmp = ptr;
        ptr = ptr->n;
        free(tmp);
    }
}

double sread(long len) {
    int i;
    long sum = 0;

    struct l *ptr;
    struct timespec tsStart, tsEnd;


    init(len);

    ptr = array;

    clock_gettime(CLOCK_REALTIME, &tsStart);
    while(ptr) {
        for(i = 0; i < NPAD; i++) {
            sum += ptr->pad[i];
        }
        ptr = ptr->n;
    }
    clock_gettime(CLOCK_REALTIME, &tsEnd);

    release();

    globalSum += sum;

    return (double)(tsEnd.tv_nsec - tsStart.tv_nsec) / (double)len;
}

最后，为了避免编译器优化，我会打印出 globalSum。如您所见，它仍然是顺序读取，我什至尝试了高达 500MB 的数组大小，每个元素的平均时间约为 4 纳秒(可能是因为它必须访问数据 'pad' 和指针 ' n'，两次访问)，等同于 1KB 的数组大小。所以，我认为这是因为像预取这样的缓存优化很好地隐藏了延迟，对吗？我会尝试随机访问，稍后将结果放上。

编辑 3

我试过随机访问链表，这是结果:

第一条红线是我的一级缓存大小，第二条是二级缓存。所以我们可以看到那里有一点跳跃。有时延迟仍然隐藏得很好。

最佳答案

这个答案不是答案，而是一组笔记。

首先，CPU 倾向于在缓存行上运行，而不是在单个字节/字/双字上运行。这意味着如果您顺序读/写一个整数数组，那么第一次访问缓存行可能会导致缓存未命中，但随后访问同一缓存行中的不同整数则不会。对于 64 字节缓存行和 4 字节整数，这意味着每 16 次访问只会出现一次缓存未命中；这会稀释结果。

其次，CPU 有一个“硬件预取器”。如果它检测到正在按顺序读取缓存行，则硬件预取器将自动预取它预测接下来将需要的缓存行(试图在需要它们之前将它们提取到缓存中)。

第三，CPU 会做其他事情(比如“乱序执行”)来隐藏获取成本。您可以测量的时间差(缓存命中和缓存未命中之间)是 CPU 无法隐藏的时间，而不是获取的总成本。

这三件事加起来意味着；对于顺序读取整数数组，当您从前一个缓存行进行 16 次读取时，CPU 可能会预取下一个缓存行；并且任何缓存未命中成本都不会引人注意，并且可能完全隐藏。为了防止这种情况；您希望“随机”访问每个缓存行一次，以最大化“工作集适合缓存”和“工作集不适合缓存”之间测量的性能差异。

最后，还有其他因素可能会影响测量。例如，对于使用分页的操作系统(例如 Linux 和几乎所有其他现代操作系统)，在这一切之上有一整层缓存(TLB/翻译后备缓冲区)，一旦工作集超过一定大小，TLB 就会丢失;这应该是图中的第四个“步骤”。还有来自内核的干扰(IRQ、页面错误、任务切换、多个 CPU 等)；这可能在图中显示为随机静态/错误(除非经常重复测试并丢弃异常值)。缓存设计(缓存关联性)也存在一些缺陷，它们会以依赖于内核分配的物理地址的方式降低缓存的有效性；这可能被视为图中转移到不同位置的“步骤”。

关于java - C、java中如何产生cpu缓存效果？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12548651/