Performance REP做什么设置?

Performance REP做什么设置?,performance,assembly,optimization,x86,cpu-architecture,Performance,Assembly,Optimization,X86,Cpu Architecture,引用《英特尔64和IA-32体系结构优化参考手册》§2.4.6“REP字符串增强”: 使用REP string的性能特征可归因于两个组件: 启动开销和数据传输吞吐量 [……] 对于更大粒度数据传输的REP字符串,作为ECX值 增加,REP String的启动开销呈逐步增加趋势: 短字符串(ECX=76: 不包括REP MOVSB):处理器实现提供硬件 通过在16字节内移动尽可能多的数据段进行优化。 如果其中一个16字节的数据 跨缓存线边界的传输跨度: 无剥离:延迟包括大约40个周期的启动成本

引用《英特尔64和IA-32体系结构优化参考手册》§2.4.6“REP字符串增强”:

使用REP string的性能特征可归因于两个组件: 启动开销和数据传输吞吐量

[……]

对于更大粒度数据传输的REP字符串,作为ECX值 增加,REP String的启动开销呈逐步增加趋势

  • 短字符串(ECX=76: 不包括REP MOVSB):处理器实现提供硬件 通过在16字节内移动尽可能多的数据段进行优化。 如果其中一个16字节的数据 跨缓存线边界的传输跨度:

    • 无剥离:延迟包括大约40个周期的启动成本,每个64字节的数据增加4个周期
    • 缓存拆分:延迟由启动组成 大约35个周期的成本,每64字节的数据增加6个周期
  • 中间字符串长度:REP MOVSW/MOVSD/MOVSQ的延迟 a大约15个周期的启动成本加上每次迭代的一个周期 word/dword/qword中的数据移动

(强调矿山)


没有进一步提到这样的启动成本。这是怎么一回事?它是做什么的?为什么总是需要更多的时间?

仅从描述中,我觉得有一个16字节的最佳传输大小,因此,如果要传输79字节,则为4*16+15。因此,不了解更多关于对齐的信息,这可能意味着15字节的前端或末尾(或拆分)都会有成本,4个16字节的传输比16的分数更快。有点像你车里的高速档,而不是通过档位换到高速档

在glibc或gcc或其他地方查看优化的memcpy。它们最多传输几个字节,然后可以进行16位传输,直到达到32位对齐、64位对齐、128位对齐地址的最佳对齐大小,然后可以对大量副本进行多字传输,然后降档,也许是一个32位的东西,也许是一个16字节,也许是一个字节,来弥补后端对齐的不足


听起来rep也在做同样的事情,先进行有效的单次传输以获得优化的对齐大小,然后进行大传输直到接近结束,然后可能进行一些小的单独传输以覆盖最后的部分。

请注意,只有
rep MOV
rep STO
是快速的
repe/ne
cmps
scas
在当前CPU上一次仅循环1个元素。(有一些性能编号,如
重复cmpsb
的每个RCX计数2个周期)。不过,它们仍有一些微码启动开销


rep movs
微码有几种策略可供选择。如果src和dest没有紧密重叠,微代码循环可以以更大的64b块传输。(这是P6引入的所谓“快速字符串”功能,偶尔会为支持更广泛加载/存储的后续CPU进行重新调整)。但是,如果dest与src只有一个字节,
rep movs
必须产生与从许多单独的
movs
指令中得到的结果完全相同的结果

因此,微码必须检查重叠,可能还有对齐(src和dest分别,或相对对齐)。它可能还会根据小/中/大计数器值选择一些内容

根据对的回答,微码中的条件分支不受分支预测的影响。因此,如果默认的未执行路径不是实际执行的路径,那么启动周期中会有很大的损失,即使对于使用相同对齐和大小的相同
rep mov
的循环也是如此

他监督了P6中最初的
rep
string实现,因此他应该知道。:)

REP MOVS使用的缓存协议功能不适用于 常规代码。基本上像SSE流媒体商店,但在某种程度上 与常规内存排序规则等兼容的// “选择和设置正确方法的巨大开销”是 主要是由于缺乏微码分支预测。我已经很久了 希望我使用硬件状态机实现了REP-mov 而不是微码,它可以完全消除 头顶

顺便说一下,我早就说过硬件可以做的事情之一 比软件更好/更快的是复杂的多路分支

自1996年奔腾Pro(P6)问世以来,英特尔x86就拥有“快速字符串”, 我监督的。P6快速字符串使用了REP MOVSB和更大的字符串 使用64位微码加载和存储以及无RFO实现它们 缓存协议。它们没有违反内存顺序,这一点与中的ERMSB不同 试管婴儿

在微码中执行快速字符串的最大缺点是(a)微码 分支预测失误,以及(b)微码与 每一代人,越来越慢,直到有人出现 去修理它。就像图书馆里的人一样,复制品也会走调。我 假设错过的机会之一可能是 在可用时使用128位加载和存储,依此类推

回想起来,我本应该编写一个自调优基础架构,以 每一代都有相当好的微代码。但这不会 帮助使用新的、更广泛的货物和商店 可用。//Linux内核似乎有这样一个自动调谐功能 启动时运行的基础架构然而,总的来说,我主张 能够在模式之间平稳过渡的硬件状态机, 不会导致分支预测失误。//是否 良好的微码分支预测可以避免这种情况

基于此,我对一个具体答案的最佳猜测是:快速通过
    REP MOVSB 10.91 B/c
    REP MOVSW 10.85 B/c
    REP MOVSD 11.05 B/c
    REP MOVSB 25.32 B/c
    REP MOVSW 19.72 B/c
    REP MOVSD 27.56 B/c
    REP MOVSQ 27.54 B/c
    REP MOVSB 21.14 B/c
    REP MOVSW 19.11 B/c
    REP MOVSD 24.27 B/c
    REP MOVSB 28.72 B/c
    REP MOVSW 19.40 B/c
    REP MOVSD 27.96 B/c
    REP MOVSQ 27.89 B/c
    REP MOVSB 57.59 B/c
    REP MOVSW 58.20 B/c
    REP MOVSD 58.10 B/c
    REP MOVSQ 57.59 B/c
    REP MOVSB 58.00 B/c
    REP MOVSW 57.69 B/c
    REP MOVSD 58.00 B/c
    REP MOVSQ 57.89 B/c