gpt4 book ai didi

performance - 内存目标 BTS 如何比 load/BTS reg,reg/store 慢得多?

转载 作者:行者123 更新时间:2023-12-03 21:11:34 29 4
gpt4 key购买 nike

在一般情况下,可以使用内存或寄存器操作数的指令如何使用内存操作数变慢然后 mov + mov -> 指令 -> mov + mov
基于在 Agner Fog's instruction tables 中发现的吞吐量和延迟(在我的情况下看 Skylake,第 238 页)
我看到以下数字为 btr/bts指示:

instruction, operands, uops fused domain, uops unfused domain, latency, throughput
mov r,r 1 1 0-1 .25
mov m,r 1 2 2 1
mov r,m 1 1 2 .5
...
bts/btr r,r 1 1 N/A .5
bts/btr m,r 10 10 N/A 5
我不明白这些数字怎么可能是正确的。即使在没有可用寄存器的最坏情况下,并且您将一个寄存器存储在临时内存位置,这样做也会更快:
## hypothetical worst-case microcode that saves/restores a scratch register
mov m,r // + 1 throughput , save a register
mov r,m // + .5 throughput , load BTS destination operand
bts r,r // + 1 throughput , do bts (or btr)
mov m,r // + 1 throughput , store result
mov r,m // + .5 throughput , restore register
作为最坏的情况,这比 bts m,r 具有更好的吞吐量(4 < 5)。 (编者注:当它们有不同的瓶颈时,将吞吐量相加不起作用。您需要考虑 uops 和端口;这个序列应该是 2c 吞吐量,瓶颈在 1/clock 存储吞吐量上。)
并且微码指令有自己的一组寄存器,因此实际上不太可能需要这样做。谁能解释为什么 bts (或通常任何指令)与使用最坏情况移动策略相比,内存、寄存器操作数可能具有更高的吞吐量。
(编者注:是的,微码可以使用一些隐藏的临时寄存器。像 add [mem], reg 这样的东西至少在逻辑上只是加载到其中之一然后存储结果。)

最佳答案

您缺少的是 BT、BTC、BTS 和 BTR 不像您在使用内存操作数时所描述的那样工作。您假设内存版本与寄存器版本的工作方式相同,但事实并非如此。对于寄存器版本,使用的第二个操作数的值取模 64(或 16 或 32)。对于内存版本,第二个操作数的值按原样使用。这意味着指令访问的实际内存位置可能不是内存操作数给出的地址,而是超过它的某个位置。
例如,忽略需要保存寄存器和原子性,得到与BTS [rsi + rdi], rax相同的操作使用 BTS 的注册版本,您需要执行以下操作:

LEA rbx, [rsi + rdi]
MOV rcx, rax
SHR rcx, 8
MOV rdx, [rbx + rcx]
BTS rdx, rax
MOV [rbx + rcx], rdx
如果您知道 RAX 的值小于 64,或者它是一个更简单的内存操作数,则可以简化此操作。事实上,正如您所注意到的,在这种情况下,使用较慢的内存版本的更快的寄存器版本可能是一个优势,即使这意味着更多的指令。

关于performance - 内存目标 BTS 如何比 load/BTS reg,reg/store 慢得多?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/63406150/

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