如何解决内存目标BTS如何比加载/ BTS reg,reg / store慢得多?
通常情况下,使用内存操作数的指令可以占用内存或寄存器操作数的速度会比mov + mov->指令-> mov + mov
慢基于Agner Fog's instruction tables中的吞吐量和延迟(在我的情况下为Skylake,p238)
我看到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,do bts (or btr)
mov m,store result
mov r,restore register
最坏的情况是吞吐量要比bts m,r
(4
而且微代码指令具有一组自己的寄存器,因此,看来不太可能实际需要这样做。谁能解释为什么bts
(或一般而言,任何指令)与使用最坏情况移动策略相比,使用内存,寄存器操作数可以具有更高的吞吐量。
(编者注:是的,微代码可以使用一些隐藏的临时寄存器。类似add [mem],reg
的东西至少在逻辑上只是加载到其中一个然后存储结果。)
解决方法
您缺少的是BT,BTC,BTS和BTR不能像使用内存操作数时所描述的那样工作。您假设内存版本与寄存器版本相同,但事实并非如此。在寄存器版本中,第二个操作数的值取模64(或16或32)。对于内存版本,第二个操作数的值照原样使用。这意味着该指令访问的实际内存位置可能不是该内存操作数给定的地址,而是它后面的某个地址。
例如,忽略保存寄存器和原子性的需要,使用BTS的寄存器版本来获得BTS [rsi + rdi],rax
的相同操作,您需要执行以下操作:
LEA rbx,[rsi + rdi]
MOV rcx,rax
SHR rcx,8
MOV rdx,[rbx + rcx]
BTS rdx,rax
MOV [rbx + rcx],rdx
如果您知道RAX的值小于64,或者它是一个更简单的内存操作数,则可以简化此操作。的确,您已经注意到,在这种情况下,使用较快的寄存器版本而不是较慢的存储器版本可能是一个优势,即使这意味着需要更多指令。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。