gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-03 10:00:07 25 4
gpt4 key购买 nike

我正在使用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_REFILLPREFETCH_LINEFILL这2个CPU事件。查看 docPREFETCH_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:

最佳答案

我将基于更多的测量和与@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。

关于linux - 当在ARM上预取更多数据时,为什么高速缓存未命中会发生更多?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/65760839/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com