gpt4 book ai didi

将带有 NT 存储的 64 字节内存复制到 1 个完整缓存行与 2 个连续的部分缓存行

转载 作者:行者123 更新时间:2023-12-04 01:37:36 24 4
gpt4 key购买 nike

我正在阅读有关写入组合内存的英特尔优化手册并编写了基准测试以了解其工作原理。这些是我正在运行基准测试的 2 个函数:
memcopy.h :

void avx_ntcopy_cache_line(void *dest, const void *src);

void avx_ntcopy_64_two_cache_lines(void *dest, const void *src);
memcopy.S :
avx_ntcopy_cache_line:
vmovdqa ymm0, [rdi]
vmovdqa ymm1, [rdi + 0x20]
vmovntdq [rsi], ymm0
vmovntdq [rsi + 0x20], ymm1
;intentionally no sfence after nt-store
ret

avx_ntcopy_64_two_cache_lines:
vmovdqa ymm0, [rdi]
vmovdqa ymm1, [rdi + 0x40]
vmovntdq [rsi], ymm0
vmovntdq [rsi + 0x40], ymm1
;intentionally no sfence after nt-store
ret

这是基准测试的主要功能的样子:
#include <stdlib.h>
#include <inttypes.h>
#include <x86intrin.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include "memcopy.h"

#define ITERATIONS 1000000

//As @HadiBrais noted, there might be an issue with 4K aliasing
_Alignas(64) char src[128];
_Alignas(64) char dest[128];

static void run_benchmark(unsigned runs, unsigned run_iterations,
void (*fn)(void *, const void*), void *dest, const void* src);

int main(void){
int fd = open("/dev/urandom", O_RDONLY);
read(fd, src, sizeof src);

run_benchmark(20, ITERATIONS, avx_ntcopy_cache_line, dest, src);
run_benchmark(20, ITERATIONS, avx_ntcopy_64_two_cache_lines, dest, src);
}

static int uint64_compare(const void *u1, const void *u2){
uint64_t uint1 = *(uint64_t *) u1;
uint64_t uint2 = *(uint64_t *) u2;
if(uint1 < uint2){
return -1;
} else if (uint1 == uint2){
return 0;
} else {
return 1;
}
}

static inline uint64_t benchmark_2cache_lines_copy_function(unsigned iterations, void (*fn)(void *, const void *),
void *restrict dest, const void *restrict src){
uint64_t *results = malloc(iterations * sizeof(uint64_t));
unsigned idx = iterations;
while(idx --> 0){
uint64_t start = __rdpmc((1<<30)+1);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
fn(dest, src);
uint64_t finish = __rdpmc((1<<30)+1);
results[idx] = (finish - start) >> 4;
}
qsort(results, iterations, sizeof *results, uint64_compare);
//median
return results[iterations >> 1];
}

static void run_benchmark(unsigned runs, unsigned run_iterations,
void (*fn)(void *, const void*), void *dest, const void* src){
unsigned current_run = 1;
while(current_run <= runs){
uint64_t time = benchmark_2cache_lines_copy_function(run_iterations, fn, dest, src);
printf("Run %d result: %lu\n", current_run, time);
current_run++;
}
}

使用选项编译
-Werror \
-Wextra
-Wall \
-pedantic \
-Wno-stack-protector \
-g3 \
-O3 \
-Wno-unused-result \
-Wno-unused-parameter

并运行基准测试我得到以下结果:

一、 avx_ntcopy_cache_line :
Run 1 result: 61
Run 2 result: 61
Run 3 result: 61
Run 4 result: 61
Run 5 result: 61
Run 6 result: 61
Run 7 result: 61
Run 8 result: 61
Run 9 result: 61
Run 10 result: 61
Run 11 result: 61
Run 12 result: 61
Run 13 result: 61
Run 14 result: 61
Run 15 result: 61
Run 16 result: 61
Run 17 result: 61
Run 18 result: 61
Run 19 result: 61
Run 20 result: 61
perf :
 Performance counter stats for './bin':

3 503 775 289 L1-dcache-loads (18,87%)
91 965 805 L1-dcache-load-misses # 2,62% of all L1-dcache hits (18,94%)
2 041 496 256 L1-dcache-stores (19,01%)
5 461 440 LLC-loads (19,08%)
1 108 179 LLC-load-misses # 20,29% of all LL-cache hits (19,10%)
18 028 817 LLC-stores (9,55%)
116 865 915 l2_rqsts.all_pf (14,32%)
0 sw_prefetch_access.t1_t2 (19,10%)
666 096 l2_lines_out.useless_hwpf (19,10%)
47 701 696 l2_rqsts.pf_hit (19,10%)
62 556 656 l2_rqsts.pf_miss (19,10%)
4 568 231 load_hit_pre.sw_pf (19,10%)
17 113 190 l2_rqsts.rfo_hit (19,10%)
15 248 685 l2_rqsts.rfo_miss (19,10%)
54 460 370 LD_BLOCKS_PARTIAL.ADDRESS_ALIAS (19,10%)
18 469 040 693 uops_retired.stall_cycles (19,10%)
16 796 868 661 uops_executed.stall_cycles (19,10%)
18 315 632 129 uops_issued.stall_cycles (19,05%)
16 176 115 539 resource_stalls.sb (18,98%)
16 424 440 816 resource_stalls.any (18,92%)
22 692 338 882 cycles (18,85%)

5,780512545 seconds time elapsed

5,740239000 seconds user
0,040001000 seconds sys

二、 avx_ntcopy_64_two_cache_lines :
Run 1 result: 6
Run 2 result: 6
Run 3 result: 6
Run 4 result: 6
Run 5 result: 6
Run 6 result: 6
Run 7 result: 6
Run 8 result: 6
Run 9 result: 6
Run 10 result: 6
Run 11 result: 6
Run 12 result: 6
Run 13 result: 6
Run 14 result: 6
Run 15 result: 6
Run 16 result: 6
Run 17 result: 6
Run 18 result: 6
Run 19 result: 6
Run 20 result: 6
perf :
 Performance counter stats for './bin':

3 095 792 486 L1-dcache-loads (19,26%)
82 194 718 L1-dcache-load-misses # 2,66% of all L1-dcache hits (18,99%)
1 793 291 250 L1-dcache-stores (19,00%)
4 612 503 LLC-loads (19,01%)
975 438 LLC-load-misses # 21,15% of all LL-cache hits (18,94%)
15 707 916 LLC-stores (9,47%)
97 928 734 l2_rqsts.all_pf (14,20%)
0 sw_prefetch_access.t1_t2 (19,21%)
532 203 l2_lines_out.useless_hwpf (19,19%)
35 394 752 l2_rqsts.pf_hit (19,20%)
56 303 030 l2_rqsts.pf_miss (19,20%)
6 197 253 load_hit_pre.sw_pf (18,93%)
13 458 517 l2_rqsts.rfo_hit (18,94%)
14 031 767 l2_rqsts.rfo_miss (18,93%)
36 406 273 LD_BLOCKS_PARTIAL.ADDRESS_ALIAS (18,94%)
2 213 339 719 uops_retired.stall_cycles (18,93%)
1 225 185 268 uops_executed.stall_cycles (18,94%)
1 943 649 682 uops_issued.stall_cycles (18,94%)
126 401 004 resource_stalls.sb (19,20%)
202 537 285 resource_stalls.any (19,20%)
5 676 443 982 cycles (19,18%)

1,521271014 seconds time elapsed

1,483660000 seconds user
0,032253000 seconds sys

可以看出,测量结果有 10 倍的差异。

我的解读 :

Intel Optimization Manual/3.6.9 中所述:

writes to different parts of the same cache line can be grouped into a single, full-cache-line bus transaction instead of going across the bus (since they are not cached) as several partial writes



我假设在 avx_ntcopy_cache_line 的情况下我们有完整的 64 字节写入启动总线事务以将它们写出禁止 rdtsc被乱序执行。

相比之下,在 avx_ntcopy_64_two_cache_lines 的情况下我们已经将 32 个字节写入到 WC 缓冲区的不同缓存行中,并且没有触发总线事务。这允许 rdtsc被乱序执行。

这种解释看起来非常可疑,与 bus-cycles 不符。区别:
avx_ntcopy_cache_line: 131 454 700 avx_ntcopy_64_two_cache_lines: 31 957 050
问题:造成这种测量差异的真正原因是什么?

最佳答案

假设:到尚未刷新的 WC 缓冲区的(完全)重叠存储可以合并到其中。完成一行会立即触发刷新,并且所有这些商店都离开核心很慢。

您报告了 100 倍以上 resource_stalls.sb全线版本比 2 部分线版本。这与这个解释是一致的。

如果 2_lines 可以将 NT 存储提交到现有的 WC 缓冲区 (LFB),则存储缓冲区可以跟上存储指令的执行速度,通常会在其他方面造成瓶颈。 (可能只是前端,考虑到每对加载/存储的调用/返回开销。当然 call 确实包含一个存储。)您的 perf结果显示 18 亿个存储(到 L1)超过 57 亿个周期,完全在 1 个存储/周期限制内,我们可能期望存储在 WC 缓冲区中命中。

但是如果 WC 缓冲区被刷新 ,当一行完全写入时发生,它必须离开核心(这很慢),将该 LFB 捆绑一段时间,以便它不能用于提交以后的 NT 存储 .当存储不能离开存储缓冲区时,它会被填满,并且核心停止为新的存储指令分配资源以进入后端。 (特别是问题/重命名/分配阶段停顿。)

您可能会通过 L2、L3、SQ、offcore req/resp 事件中的任何一个更清楚地看到这种效果,这些事件会在 L1 之外接收所有这些流量。您包括了一些 L2 柜台,但那些可能不会选择通过 L2 的 NT 商店。

Enhanced REP MOVSB for memcpy建议 NT 存储需要更长的时间让 LFB“切换”到内存层次结构的外部级别 ,在请求开始其旅程后长时间保持 LFB 被占用。 (也许是为了确保核心始终可以重新加载它刚刚存储的内容,否则不会丢失对运行中的 NT 存储的跟踪以保持与 MESI 的一致性。)稍后 sfence还需要知道较早的 NT 存储何时对其他内核可见,因此在此之前我们不能让它们不可见。

即使情况并非如此,对于所有这些 NT 存储请求,某处仍然存在吞吐量瓶颈。所以另一种可能的机制是,它们填充一些缓冲区,然后内核不能再切换 LFB,所以它用完了 LFB 来提交 NT 存储,然后 SB 填充停止分配。

一旦它们到达内存 Controller ,它们可能会合并,而每个都不需要通过实际的外部内存总线进行突发传输,但是从内核通过非内核到内存 Controller 的路径并不短。

甚至做 2x rdpmc每 32 个存储不会降低 CPU 的速度以防止存储缓冲区被填满;您所看到的取决于在相对紧凑的循环中运行它,而不是开始时使用空存储缓冲区的一次性执行。另外,您的建议是 rdpmcrdtsc不会被重新排序。 WC 缓冲区刷新为零意义。商店的执行不是命令wrt。执行 rdtsc .

TL:DR: 您的 rdpmc为单个存储组计时是没有帮助的,如果有任何东西通过减慢不会在存储缓冲区上造成瓶颈的快速情况来隐藏某些性能差异。

关于将带有 NT 存储的 64 字节内存复制到 1 个完整缓存行与 2 个连续的部分缓存行,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59801090/

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