linux - 当在ARM上预取更多数据时，为什么高速缓存未命中会发生更多？

Question

我正在使用OProfile在树莓派3B +上分析以下功能。 (我在树莓派上使用的是gcc版本10.2(不进行交叉编译)，并且为编译器使用了以下标志:-O1 -mfpu-neon -mneon-for-64bits。最后包含了生成汇编代码。)

void do_stuff_u32(const uint32_t* a, const uint32_t* b, uint32_t* c, size_t array_size)
{
  for (int i = 0; i < array_size; i++)
  {

    uint32_t tmp1 = b[i];
    uint32_t tmp2 = a[i];
    c[i] = tmp1 * tmp2;
  }
}

我正在查看L1D_CACHE_REFILL和PREFETCH_LINEFILL这2个CPU事件。查看doc，PREFETCH_LINEFILL计算由于预取而导致的缓存行填充数，而L1D_CACHE_REFILL计算由于缓存未命中而导致的缓存行重新填充数。对于以上循环，我得到了以下结果:


array_size
array_size/L1D_CACHE_REFILL
array_size/PREFETCH_LINEFILL


16777216
18.24
8.366


我可以想象上述循环是受内存限制的，它可以通过值8.366确认:每个循环实例需要3 x uint32_t，即12B。并且8.366循环实例需要从内存中获取约100B的数据。但是，预取器只能在每8.366个循环实例中向L1填充1条缓存行，根据Cortex-A53的手册，该实例具有64B。因此，其余的缓存访问将导致缓存未命中，即18.24。如果将这两个数字相加，则得到的结果约为5.7，这意味着每5.7个循环实例从预取或缓存未命中填充中填充1个缓存行。 5.7个循环实例需要5.7 x 3 x 4 = 68B，这与缓存行大小基本一致。
然后，我在循环中添加了更多内容，然后变为:

void do_more_stuff_u32(const uint32_t* a, const uint32_t* b, uint32_t* c, size_t array_size)
{
  for (int i = 0; i < array_size; i++)
  {

    uint32_t tmp1 = b[i];
    uint32_t tmp2 = a[i];
    tmp1 = tmp1 * 17;
    tmp1 = tmp1 + 59;
    tmp1 = tmp1 /2;
    tmp2 = tmp2 *27;
    tmp2 = tmp2 + 41;
    tmp2 = tmp2 /11;
    tmp2 = tmp2 + tmp2;
    c[i] = tmp1 * tmp2;
  }
}

我不了解cpu事件的分析数据:


array_size
array_size/L1D_CACHE_REFILL
array_size/PREFETCH_LINEFILL


16777216
11.24
7.034


由于执行循环需要更长的时间，因此预取程序现在仅需要7.034个循环实例来填充1个缓存行。但是我不明白的是，为什么高速缓存未命中也比以前的18.24更加频繁地发生(由数字11.24反射(reflect)出来)？有人可以阐明所有这些如何组合吗？

更新以包括生成的程序集
回路1:

    cbz x3, .L178
    lsl x6, x3, 2
    mov x3, 0
.L180:
    ldr w4, [x1, x3]
    ldr w5, [x0, x3]
    mul w4, w4, w5
    lsl w4, w4, 1
    str w4, [x2, x3]
    add x3, x3, 4
    cmp x3, x6
    bne .L180
.L178:

Loop2:

    cbz x3, .L178
    lsl x6, x3, 2
    mov x5, 0
    mov w8, 27
    mov w7, 35747
    movk    w7, 0xba2e, lsl 16
.L180:
    ldr w3, [x1, x5]
    ldr w4, [x0, x5]
    add w3, w3, w3, lsl 4
    add w3, w3, 59
    mul w4, w4, w8
    add w4, w4, 41
    lsr w3, w3, 1
    umull   x4, w4, w7
    lsr x4, x4, 35
    mul w3, w3, w4
    lsl w3, w3, 1
    str w3, [x2, x5]
    add x5, x5, 4
    cmp x5, x6
    bne .L180
.L178:

Answer 1

我将基于更多的测量和与@artlessnoise的讨论，尝试回答我自己的问题。
我进一步测量了上述两个循环的READ_ALLOC_ENTER事件，并具有以下数据:
循环1


数组大小
READ_ALLOC_ENTER


16777216
12494

循环2


数组大小
READ_ALLOC_ENTER


16777216
1933年


因此，显然，小循环(第一个)输入Read Allocate Mode比大循环(第二个)要多得多，这可能是由于CPU能够更轻松地检测到连续的写模式。在读取分配模式下，存储直接转到L2(如果L1没有命中)。这就是为什么第一个循环的L1D_CACHE_REFILL较小的原因，因为它涉及的L1较少。对于第二个循环，由于与第一个循环相比，它需要L1来更频繁地更新c[]，因此由于缓存未命中而导致的重新填充可能会更多。此外，对于第二种情况，由于L1经常被c[]占用更多的缓存行，因此会影响a[]和b[]的缓存命中率，从而影响更多的L1D_CACHE_REFILL。