gpt4 book ai didi

c - 为什么 memcpy 在 32 位模式下使用 gcc -march=native 在 Ryzen 上对于大缓冲区很慢?

转载 作者:太空狗 更新时间:2023-10-29 15:28:19 28 4
gpt4 key购买 nike

我写了一个简单的测试(代码在底部)来测试我的 64 位 Debian 系统上 memcpy 的性能。在我的系统上,当编译为 64 位二进制文​​件时,这会在所有 block 大小上提供一致的 38-40GB/s。然而,当在同一系统上构建为 32 位二进制文​​件时,复制性能非常糟糕。

我在汇编器中编写了自己的 memcpy 实现,它利用能够匹配 64 位性能的 SIMD。老实说,我自己的 memcpy 比 native 快得多,我真的很震惊,肯定是 32 位 libc 构建有问题。

32位memcpy测试结果

0x00100000 B, 0.034215 ms, 29227.06 MB/s (16384 iterations)
0x00200000 B, 0.033453 ms, 29892.56 MB/s ( 8192 iterations)
0x00300000 B, 0.048710 ms, 20529.48 MB/s ( 5461 iterations)
0x00400000 B, 0.049187 ms, 20330.54 MB/s ( 4096 iterations)
0x00500000 B, 0.058945 ms, 16965.01 MB/s ( 3276 iterations)
0x00600000 B, 0.060735 ms, 16465.01 MB/s ( 2730 iterations)
0x00700000 B, 0.068973 ms, 14498.34 MB/s ( 2340 iterations)
0x00800000 B, 0.078325 ms, 12767.34 MB/s ( 2048 iterations)
0x00900000 B, 0.099801 ms, 10019.92 MB/s ( 1820 iterations)
0x00a00000 B, 0.111160 ms, 8996.04 MB/s ( 1638 iterations)
0x00b00000 B, 0.120044 ms, 8330.31 MB/s ( 1489 iterations)
0x00c00000 B, 0.116506 ms, 8583.26 MB/s ( 1365 iterations)
0x00d00000 B, 0.120322 ms, 8311.06 MB/s ( 1260 iterations)
0x00e00000 B, 0.114424 ms, 8739.40 MB/s ( 1170 iterations)
0x00f00000 B, 0.128843 ms, 7761.37 MB/s ( 1092 iterations)
0x01000000 B, 0.118122 ms, 8465.85 MB/s ( 1024 iterations)
0x08000000 B, 0.140218 ms, 7131.76 MB/s ( 128 iterations)
0x10000000 B, 0.115596 ms, 8650.85 MB/s ( 64 iterations)
0x20000000 B, 0.115325 ms, 8671.16 MB/s ( 32 iterations)

64位memcpy测试结果

0x00100000 B, 0.022237 ms, 44970.48 MB/s (16384 iterations)
0x00200000 B, 0.022293 ms, 44856.77 MB/s ( 8192 iterations)
0x00300000 B, 0.021729 ms, 46022.49 MB/s ( 5461 iterations)
0x00400000 B, 0.028348 ms, 35275.28 MB/s ( 4096 iterations)
0x00500000 B, 0.026118 ms, 38288.08 MB/s ( 3276 iterations)
0x00600000 B, 0.026161 ms, 38225.15 MB/s ( 2730 iterations)
0x00700000 B, 0.026199 ms, 38169.68 MB/s ( 2340 iterations)
0x00800000 B, 0.026236 ms, 38116.22 MB/s ( 2048 iterations)
0x00900000 B, 0.026090 ms, 38329.50 MB/s ( 1820 iterations)
0x00a00000 B, 0.026085 ms, 38336.39 MB/s ( 1638 iterations)
0x00b00000 B, 0.026079 ms, 38345.59 MB/s ( 1489 iterations)
0x00c00000 B, 0.026147 ms, 38245.75 MB/s ( 1365 iterations)
0x00d00000 B, 0.026033 ms, 38412.69 MB/s ( 1260 iterations)
0x00e00000 B, 0.026037 ms, 38407.40 MB/s ( 1170 iterations)
0x00f00000 B, 0.026019 ms, 38433.80 MB/s ( 1092 iterations)
0x01000000 B, 0.026041 ms, 38401.61 MB/s ( 1024 iterations)
0x08000000 B, 0.026123 ms, 38280.89 MB/s ( 128 iterations)
0x10000000 B, 0.026083 ms, 38338.70 MB/s ( 64 iterations)
0x20000000 B, 0.026116 ms, 38290.93 MB/s ( 32 iterations)

自定义 32 位 memcpy
0x00100000 B, 0.026807 ms, 37303.21 MB/s (16384 iterations)
0x00200000 B, 0.026500 ms, 37735.59 MB/s ( 8192 iterations)
0x00300000 B, 0.026810 ms, 37300.04 MB/s ( 5461 iterations)
0x00400000 B, 0.026214 ms, 38148.05 MB/s ( 4096 iterations)
0x00500000 B, 0.026738 ms, 37399.74 MB/s ( 3276 iterations)
0x00600000 B, 0.026035 ms, 38409.15 MB/s ( 2730 iterations)
0x00700000 B, 0.026262 ms, 38077.29 MB/s ( 2340 iterations)
0x00800000 B, 0.026190 ms, 38183.00 MB/s ( 2048 iterations)
0x00900000 B, 0.026287 ms, 38042.18 MB/s ( 1820 iterations)
0x00a00000 B, 0.026263 ms, 38076.66 MB/s ( 1638 iterations)
0x00b00000 B, 0.026162 ms, 38223.48 MB/s ( 1489 iterations)
0x00c00000 B, 0.026189 ms, 38183.45 MB/s ( 1365 iterations)
0x00d00000 B, 0.026012 ms, 38444.52 MB/s ( 1260 iterations)
0x00e00000 B, 0.026089 ms, 38330.05 MB/s ( 1170 iterations)
0x00f00000 B, 0.026373 ms, 37917.10 MB/s ( 1092 iterations)
0x01000000 B, 0.026304 ms, 38016.85 MB/s ( 1024 iterations)
0x08000000 B, 0.025958 ms, 38523.59 MB/s ( 128 iterations)
0x10000000 B, 0.025992 ms, 38473.84 MB/s ( 64 iterations)
0x20000000 B, 0.026020 ms, 38431.96 MB/s ( 32 iterations)

测试程序

(编译:gcc -m32 -march=native -O3)

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <stdint.h>
#include <malloc.h>

static inline uint64_t nanotime()
{
struct timespec time;
clock_gettime(CLOCK_MONOTONIC_RAW, &time);
return ((uint64_t)time.tv_sec * 1e9) + time.tv_nsec;
}

void test(const int size)
{
char * buffer1 = memalign(128, size);
char * buffer2 = memalign(128, size);

for(int i = 0; i < size; ++i)
buffer2[i] = i;

uint64_t t = nanotime();
const uint64_t loops = (16384LL * 1048576LL) / size;
for(uint64_t i = 0; i < loops; ++i)
memcpy(buffer1, buffer2, size);
double ms = (((float)(nanotime() - t) / loops) / 1000000.0f) / (size / 1024 / 1024);
printf("0x%08x B, %8.6f ms, %8.2f MB/s (%5llu iterations)\n", size, ms, 1000.0 / ms, loops);

// prevent the compiler from trying to optimize out the copy
if (buffer1[0] == 0x0)
return;

free(buffer1);
free(buffer2);
}

int main(int argc, char * argv[])
{
for(int i = 0; i < 16; ++i)
test((i+1) * 1024 * 1024);

test(128 * 1024 * 1024);
test(256 * 1024 * 1024);
test(512 * 1024 * 1024);
return 0;
}

编辑

  • 在 Ryzen 7 和 ThreadRipper 1950x 上测试
  • glibc:2.27
  • 海湾合作委员会:7.3.0

性能结果:

  99.68%  x32.n.bin  x32.n.bin          [.] test
0.28% x32.n.bin [kernel.kallsyms] [k] clear_page_rep
0.01% x32.n.bin [kernel.kallsyms] [k] get_page_from_freelist
0.01% x32.n.bin [kernel.kallsyms] [k] __mod_node_page_state
0.01% x32.n.bin [kernel.kallsyms] [k] page_fault
0.00% x32.n.bin [kernel.kallsyms] [k] default_send_IPI_single
0.00% perf_4.17 [kernel.kallsyms] [k] __x86_indirect_thunk_r14

自定义 SSE 实现

inline static void memcpySSE(void *dst, const void * src, size_t length)
{
#if (defined(__x86_64__) || defined(__i386__))
if (length == 0 || dst == src)
return;

#ifdef __x86_64__
const void * end = dst + (length & ~0xFF);
size_t off = (15 - ((length & 0xFF) >> 4));
off = (off < 8) ? off * 16 : 7 * 16 + (off - 7) * 10;
#else
const void * end = dst + (length & ~0x7F);
const size_t off = (7 - ((length & 0x7F) >> 4)) * 10;
#endif

#ifdef __x86_64__
#define REG "rax"
#else
#define REG "eax"
#endif

__asm__ __volatile__ (
"cmp %[dst],%[end] \n\t"
"je Remain_%= \n\t"

// perform SIMD block copy
"loop_%=: \n\t"
"vmovaps 0x00(%[src]),%%xmm0 \n\t"
"vmovaps 0x10(%[src]),%%xmm1 \n\t"
"vmovaps 0x20(%[src]),%%xmm2 \n\t"
"vmovaps 0x30(%[src]),%%xmm3 \n\t"
"vmovaps 0x40(%[src]),%%xmm4 \n\t"
"vmovaps 0x50(%[src]),%%xmm5 \n\t"
"vmovaps 0x60(%[src]),%%xmm6 \n\t"
"vmovaps 0x70(%[src]),%%xmm7 \n\t"
#ifdef __x86_64__
"vmovaps 0x80(%[src]),%%xmm8 \n\t"
"vmovaps 0x90(%[src]),%%xmm9 \n\t"
"vmovaps 0xA0(%[src]),%%xmm10 \n\t"
"vmovaps 0xB0(%[src]),%%xmm11 \n\t"
"vmovaps 0xC0(%[src]),%%xmm12 \n\t"
"vmovaps 0xD0(%[src]),%%xmm13 \n\t"
"vmovaps 0xE0(%[src]),%%xmm14 \n\t"
"vmovaps 0xF0(%[src]),%%xmm15 \n\t"
#endif
"vmovntdq %%xmm0 ,0x00(%[dst]) \n\t"
"vmovntdq %%xmm1 ,0x10(%[dst]) \n\t"
"vmovntdq %%xmm2 ,0x20(%[dst]) \n\t"
"vmovntdq %%xmm3 ,0x30(%[dst]) \n\t"
"vmovntdq %%xmm4 ,0x40(%[dst]) \n\t"
"vmovntdq %%xmm5 ,0x50(%[dst]) \n\t"
"vmovntdq %%xmm6 ,0x60(%[dst]) \n\t"
"vmovntdq %%xmm7 ,0x70(%[dst]) \n\t"
#ifdef __x86_64__
"vmovntdq %%xmm8 ,0x80(%[dst]) \n\t"
"vmovntdq %%xmm9 ,0x90(%[dst]) \n\t"
"vmovntdq %%xmm10,0xA0(%[dst]) \n\t"
"vmovntdq %%xmm11,0xB0(%[dst]) \n\t"
"vmovntdq %%xmm12,0xC0(%[dst]) \n\t"
"vmovntdq %%xmm13,0xD0(%[dst]) \n\t"
"vmovntdq %%xmm14,0xE0(%[dst]) \n\t"
"vmovntdq %%xmm15,0xF0(%[dst]) \n\t"

"add $0x100,%[dst] \n\t"
"add $0x100,%[src] \n\t"
#else
"add $0x80,%[dst] \n\t"
"add $0x80,%[src] \n\t"
#endif
"cmp %[dst],%[end] \n\t"
"jne loop_%= \n\t"

"Remain_%=: \n\t"

// copy any remaining 16 byte blocks
#ifdef __x86_64__
"leaq (%%rip), %%rax\n\t"
#else
"call GetPC_%=\n\t"
#endif
"Offset_%=:\n\t"
"add $(BlockTable_%= - Offset_%=), %%" REG "\n\t"
"add %[off],%%" REG " \n\t"
"jmp *%%" REG " \n\t"

#ifdef __i386__
"GetPC_%=:\n\t"
"mov (%%esp), %%eax \n\t"
"ret \n\t"
#endif

"BlockTable_%=:\n\t"
#ifdef __x86_64__
"vmovaps 0xE0(%[src]),%%xmm14 \n\t"
"vmovntdq %%xmm14,0xE0(%[dst]) \n\t"
"vmovaps 0xD0(%[src]),%%xmm13 \n\t"
"vmovntdq %%xmm13,0xD0(%[dst]) \n\t"
"vmovaps 0xC0(%[src]),%%xmm12 \n\t"
"vmovntdq %%xmm12,0xC0(%[dst]) \n\t"
"vmovaps 0xB0(%[src]),%%xmm11 \n\t"
"vmovntdq %%xmm11,0xB0(%[dst]) \n\t"
"vmovaps 0xA0(%[src]),%%xmm10 \n\t"
"vmovntdq %%xmm10,0xA0(%[dst]) \n\t"
"vmovaps 0x90(%[src]),%%xmm9 \n\t"
"vmovntdq %%xmm9 ,0x90(%[dst]) \n\t"
"vmovaps 0x80(%[src]),%%xmm8 \n\t"
"vmovntdq %%xmm8 ,0x80(%[dst]) \n\t"
"vmovaps 0x70(%[src]),%%xmm7 \n\t"
"vmovntdq %%xmm7 ,0x70(%[dst]) \n\t"
#endif
"vmovaps 0x60(%[src]),%%xmm6 \n\t"
"vmovntdq %%xmm6 ,0x60(%[dst]) \n\t"
"vmovaps 0x50(%[src]),%%xmm5 \n\t"
"vmovntdq %%xmm5 ,0x50(%[dst]) \n\t"
"vmovaps 0x40(%[src]),%%xmm4 \n\t"
"vmovntdq %%xmm4 ,0x40(%[dst]) \n\t"
"vmovaps 0x30(%[src]),%%xmm3 \n\t"
"vmovntdq %%xmm3 ,0x30(%[dst]) \n\t"
"vmovaps 0x20(%[src]),%%xmm2 \n\t"
"vmovntdq %%xmm2 ,0x20(%[dst]) \n\t"
"vmovaps 0x10(%[src]),%%xmm1 \n\t"
"vmovntdq %%xmm1 ,0x10(%[dst]) \n\t"
"vmovaps 0x00(%[src]),%%xmm0 \n\t"
"vmovntdq %%xmm0 ,0x00(%[dst]) \n\t"
"nop\n\t"
"nop\n\t"

: [dst]"+r" (dst),
[src]"+r" (src)
: [off]"r" (off),
[end]"r" (end)
: REG,
"xmm0",
"xmm1",
"xmm2",
"xmm3",
"xmm4",
"xmm5",
"xmm6",
"xmm7",
#ifdef __x86_64__
"xmm8",
"xmm9",
"xmm10",
"xmm11",
"xmm12",
"xmm13",
"xmm14",
"xmm15",
#endif
"memory"
);

#undef REG

//copy any remaining bytes
for(size_t i = (length & 0xF); i; --i)
((uint8_t *)dst)[length - i] =
((uint8_t *)src)[length - i];
#else
memcpy(dst, src, length);
#endif
}

带有-O3 -m32 -march=znver1的原生memcpy

  cmp ebx, 4
jb .L56
mov ecx, DWORD PTR [ebp+0]
lea edi, [eax+4]
mov esi, ebp
and edi, -4
mov DWORD PTR [eax], ecx
mov ecx, DWORD PTR [ebp-4+ebx]
mov DWORD PTR [eax-4+ebx], ecx
mov ecx, eax
sub ecx, edi
sub esi, ecx
add ecx, ebx
shr ecx, 2
rep movsd
jmp .L14

最佳答案

Could it be that the debian libc-i386 is not compiled with SSE support?... Confirmed, objdump shows no SSE used in the memcpy inlined.

除非您使用 -fno-builtin-memcpy,否则 GCC 将 memcpy 视为内置;正如您从 perf 中看到的,甚至没有调用 libc.so 中的 asm 实现。 (而且 gcc 不能从共享库中内联代码。glibc 头文件只有原型(prototype),没有内联 asm 实现。)

将 memcpy 内联为 rep movs 纯粹是 GCC 的想法,使用 gcc -O3 -m32 -march=znver1。 (还有 the OP reports -fno-builtin-memcpy 加速了这个微基准测试,所以显然 glibc 的手写 asm 实现很好。这是预期的;它可能与 64 位大致相同,并且不'受益于超过 8 个 XMM 或 YMM 寄存器。)

我强烈建议反对一般情况下使用-fno-builtin-memcpy,因为您绝对希望 gcc 内联 memcpy 用于 float foo; int32_t 栏; memcpy(&foo, &bar, sizeof(foo));.或者其他可以内联为单个 vector 加载/存储的小型固定大小情况。您肯定希望 gcc 理解 memcpy 只是复制内存,而不是将其视为不透明函数。

长期的解决方案是让 gcc 在 Zen 上不将 memcpy 内联为 rep movs;显然,当副本可能很大时,这不是一个好的调整决定。 IDK 如果它适合小副本;英特尔的启动开销很大。

短期解决方案是手动调用您的自定义 memcpy(或以某种方式调用非内置 glibc memcpy),因为您知道副本通常很大,但让 gcc 在其他情况下使用其内置。 super 丑陋的方法是使用 -fno-builtin-memcpy 然后使用 __builtin_memcpy 而不是 memcpy 进行小拷贝。


看起来对于大缓冲区,rep movs 与 NT 商店相比,Ryzen 上的效果并不好。在 Intel 上,我认为 rep movs 应该使用类似于 NT 存储的无 RFO 协议(protocol),但也许 AMD 不同。

Enhanced REP MOVSB for memcpy只提到英特尔,但它确实有一些关于带宽受内存/L3 延迟和最大并发限制的细节,而不是实际的 DRAM Controller 带宽限制。


顺便说一句,您的自定义版本甚至在选择使用 NT 商店之前检查大小阈值吗?如果要立即再次加载数据,NT 存储会占用中小型缓冲区;它必须来自 DRAM 而不是 L1d 命中。

关于c - 为什么 memcpy 在 32 位模式下使用 gcc -march=native 在 Ryzen 上对于大缓冲区很慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/50422510/

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