【问题标题】:why glibc memcpy not choose avx512 version?为什么glibc memcpy不选择avx512版本?
【发布时间】:2021-06-29 13:05:37
【问题描述】:

我在下面编译了一个示例代码:

 #cat array_addition.c 
 #define MAX 1000000
 #define S 1024
 #include <string.h>
int a[S], b[S], c[S];

__attribute__((target_clones("avx512f", "avx2","arch=atom","default")))
void foo(int argc){
    int i,x;

for (x=0; x<1024; x++){
    for (i=0; i<S; i++){
        a[i] = b[i] + c[i];
    }
}
    b[0] = argc;
    memcpy(&a[0], &b[0], argc *sizeof(int));
}
int main(int argc, char** argv) {
    foo(argc);
    return 0;
}

调用memcpy;

从 objdump 中,我们可以发现它会调用 GLIBC memcpy:

#readelf -r a.out 

Relocation section '.rela.dyn' at offset 0x418 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000403ff8  000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0

Relocation section '.rela.plt' at offset 0x430 contains 4 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000404018  000100000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main@GLIBC_2.2.5 + 0
000000404020  000200000007 R_X86_64_JUMP_SLO 0000000000000000 __gmon_start__ + 0
000000404028  000300000007 R_X86_64_JUMP_SLO 0000000000000000 memcpy@GLIBC_2.14 + 0
000000404030  000000000025 R_X86_64_IRELATIV                    4018f0

然后,我使用 gdb 来跟踪它使用了哪个 glibc 实现;

(gdb) b memcpy@plt    
Breakpoint 1 at 0x401050
(gdb) s
The program is not being run.
(gdb) r
Starting program: /root/a.out 

Breakpoint 1, 0x0000000000401050 in memcpy@plt ()
(gdb) s
Single stepping until exit from function memcpy@plt,
which has no line number information.
0x00007ffff7b623a0 in __memcpy_ssse3_back () from /lib64/libc.so.6
(gdb) info function __memcpy_*
All functions matching regular expression "__memcpy_*":

Non-debugging symbols:
0x00007ffff7aa2840  __memcpy_chk_sse2
0x00007ffff7aa2850  __memcpy_sse2
0x00007ffff7ab1b40  __memcpy_chk_avx512_no_vzeroupper
0x00007ffff7ab1b50  __memcpy_avx512_no_vzeroupper
0x00007ffff7b23360  __memcpy_chk
0x00007ffff7b5a470  __memcpy_chk_ssse3
0x00007ffff7b5a480  __memcpy_ssse3
0x00007ffff7b62390  __memcpy_chk_ssse3_back
0x00007ffff7b623a0  __memcpy_ssse3_back
(gdb) 

有__memcpy_avx512_no_zeroupper,但没有被选中;

而且我的 cpu 支持它的功能:

标志:fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 系统调用 nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 显示器 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke flush_l1d

gcc 版本:

使用内置规范。 COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/root/china-gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper 目标:x86_64-pc-linux-gnu 配置:./configure --prefix=/root/china-gcc-10.2.0 --disable-multilib 线程模型:posix 支持的LTO压缩算法:zlib gcc version 10.2.0 (GCC)

【问题讨论】:

  • Glibc 是免费软件。您可以下载它的源代码,研究它并改进它

标签: c compiler-optimization glibc avx512


【解决方案1】:

在 Skylake-X 和 IceLake 等“主流” CPU 上,如果您在程序的大部分运行时(而不仅仅是偶尔的 memcpy)中始终使用 512 位向量,则完全值得使用 512 位向量。 (而且如果您的程序将运行很长时间,否则您会减慢通过上下文切换和/或超线程共享相同物理内核的其他进程。)有关详细信息,请参阅SIMD instructions lowering CPU frequency:您不希望偶尔调用 memcpy 以将您的 CPU 频率降低到较低的最大 turbo。

在某些方面使用 AVX-512 功能和 256 位向量 (AVX-512VL) 可能是值得的,例如如果掩蔽很好,或者如果您使用 YMM16..31 来避免 VZEROUPPER。

我猜 glibc 只会在 Knight's Landing (KNL) Xeon Phi 等系统上将 memcpy 解析为 __memcpy_avx512_no_vzeroupper,其中 CPU 是围绕 AVX-512 设计的,使用 512 位 ZMM 向量没有缺点。即使在 KNL 上使用 ymm0..15 后,也不需要 vzeroupper。事实上,vzeroupper 在 KNL 上非常慢,绝对要避免,因此将 no_vzeroupper 放在函数名中。

https://code.woboq.org/userspace/glibc/sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S.html 是该版本的来源。它使用 ZMM 向量,包括 ZMM0..15,因此如果在 Skylake/IceLake CPU 上使用它应该使用 vzeroupper。 这个版本看起来是为 KNL 设计的。


拥有一个使用 ymm16..31 的 AVX-512VL 版本可以避免使用 vzeroupper(以加快 32 .. 64 字节副本的速度),而无需使用 ZMM 寄存器。

__memcpy_avx512_no_vzeroupper 只使用 ZMM16..31 是有意义的,因此避免 vzeroupper 在主流 CPU 上不是问题;那么这将是已经大量使用 AVX-512 的代码中的一个可用选项(因此已经支付了 CPU 频率成本。)

【讨论】:

  • 所以 __memcpy_sse3 最适合我的 CPU?如果 cpy 的内存非常大,glibc 是否使用更高性能的方法,例如 vmovntq ?希望阐明选择不同实现的策略:)
  • @Chinaxing:我希望在您的 Skylake-X 系统上使用 __memcpy_avx_unaligned_erms,就像我的 Skylake 桌面一样。 (code.woboq.org/userspace/glibc/sysdeps/x86_64/multiarch/…)。也许您的发行版错误配置了 glibc 以省略和 AVX1 / rep movsb 版本。 ssse3 版本甚至避免了 256 位向量。
  • 这是否取决于 glibc 版本?我使用 glibc 2.17。也许太旧了?
  • @Chinaxing:不太可能;毕竟,您的 glibc 足够新,可以拥有 AVX512! AVX1 在此之前已经存在了几年,大约从 2011 年开始。
  • @PeterCordes 最近因为vzeroupper 中止事务,他们添加了几乎所有字符串函数的zmm16...31 版本。 Memmove commit
猜你喜欢
  • 1970-01-01
  • 2022-10-25
  • 2016-05-14
  • 1970-01-01
  • 2014-06-09
  • 1970-01-01
  • 1970-01-01
  • 2021-09-18
  • 2021-08-17
相关资源
最近更新 更多