Skylake是否需要vzeroupper，以便在512位指令仅读取ZMM寄存器、写入k掩码后恢复turbo时钟？
写入ZMM寄存器可以使Skylake-X（或类似）CPU无限期地处于最大turbo减少的状态。（SIMD指令降低CPU频率，并动态确定恶意AVX-512指令的执行位置）冰湖可能与此类似。
（解决方法：zmm16没有问题...31，根据我在@BeeOnRope中引用的评论，如果您的程序库不包含SSE指令，使用VZEROUPPER有用吗？所以这个strlen可以只使用vpxord xmm16、xmm16、xmm16和vpcmpeqb与zmm16。）
@BeeOnRope在RWT线程中发布了测试代码：将vBroadastsd zmm15，[zero_dp]替换为vpcmpeqb k0， zmm0，[rdi]作为“脏”指令，并查看之后的循环运行速度是慢还是快。
我假设执行任何512位uop会暂时触发减少的turbo（同时关闭向量ALU uop的端口1，而512位uop实际上在后端），但问题是：如果您在读取ZMM寄存器后从不使用vzeroupper，CPU会自行恢复吗？
（和/或以后的SSE或AVX指令会有过渡惩罚或错误依赖项吗？）
具体来说，像这样使用insns的strlen在返回之前需要vzeroupper吗？（在任何真正的中央处理器上实践，和/或如英特尔为面向未来的最佳实践所记录的那样。）假设以后的指令可能包括非VEX SSE和/或VEX编码的AVX1/2，而不仅仅是GP整数，以防这与保持涡轮增压降低的脏上256情况相关。
; check 64 bytes for zero, strlen building block.
vpxor xmm0,xmm0,xmm0 ; zmm0 = 0 using AVX1 implicit zero-extension
vpcmpeqb k0, zmm0, [rdi] ; 512-bit load + ALU, not micro-fused
;kortestq k0,k0 / jnz or whatever
kmovq rax, k0
tzcnt rax, rax
;vzeroupper before lots of code that goes a long time before another 512-bit uop?
（灵感来源于AVX512BW中的strlen：使用bsf/tzcnt处理32位代码中的64位掩码？如果将其矢量寄存器归零进行了适当优化，以使用较短的VEX而不是EVEX指令，则会出现这种情况。）
关键指令是vpcmpeqb k0，zmm0，[rdi]，它在SKX或CNL上解码为2个单独的UOP（非微融合：失效插槽=2.0）：512位加载（进入512位物理寄存器？）并将ALU比较到掩码寄存器中。
但是没有架构ZMM寄存器是显式写入的，只有读的。所以大概至少一个xSave/xrstor可以清除任何“脏上层”条件，如果在此之后存在的话。（这不会发生在Linux除非有一个实际的上下文切换到该内核上的不同用户空间进程，或者线程迁移；仅仅进入内核进行中断不会导致它。所以如果你有硬件，这实际上仍然是可以在主流操作系统下测试的；我没有。）
我可以想象SKX/CNL和/或冰湖的可能性：
- 没有长期影响：max-turbo恢复速度与
vzeroupper - 最大turbo限制为512位速度，直到上下文切换。（
xrstor或等效清除任何脏上状态标志，因为架构规则是干净的）。 - 即使跨上下文切换，最大turbo速度也限制为512位，就像您运行
vaddps zmm0， zmm0， zmm0一样。（肮脏的上层标志设置在保存中并与架构状态一起恢复。）可能是合理的，因为xsaveop确实跳过保存向量规则的上层128或256，如果知道它们是干净的。
我假设kmovq不会减少max-turbo或触发任何其他512位uop效应。掩码寄存器的上32位通常仅与64字节向量的AVX512BW一起使用，但它们可能不会分别对掩码寄存器的前32位进行功率门，仅对向量寄存器的前32位进行功率门。有一些用例，例如使用kshift或kunpack来处理64位掩码块（用于加载/存储或传输到整数regs），即使您在带有YMM或XMM regs的AVX512VL中一次只生成或使用32位掩码。
PS:Xeon Phi不受这些影响；当运行其他代码时，它并不是为了在重型AVX512之外增加时钟，因为它是为运行AVX512而设计的。事实上，vzeroupper非常慢，不推荐用于KNL/KNM。
我的示例使用AVX512BW的事实实际上与这个问题无关，但所有主流（非Xeon Phi）使用AVX512的CPU都有AVX512BW。它只是一个很好的真实用例，使用AVX512BW排除KNL这一事实无关紧要。
共有1个答案
不，如果使用zmm寄存器作为比较变量之一，则进入掩码寄存器的vpcmpeqb不会触发慢模式，至少在SKX上是这样。
这也适用于任何其他仅读取键512位寄存器（键寄存器为zmm0-zmm15）的指令（据我测试）。例如，vpxord zmm16、zmm0、zmm1也不会弄脏鞋面，因为虽然它涉及作为密钥寄存器的zmm1和zmm0，但它仅在写入不是密钥寄存器的zmm16时读取。
我在Xeon W-2104上使用avx turbo进行了测试，其标称速度为3.2 GHz，L1 turbo许可证（AVX2 turbo）为2.8 GHz，L2许可证（avx-512 turbo）为2.4 GHz。在每次测试之前，我用vpxord zmm15，zmm14，zmm15选项弄脏鞋面。这会导致任何使用任何SIMD寄存器（包括标量SSE FP）的测试以较慢的2.8 GHz速度运行，如这些结果所示（查看A/M-MHz列中的cpu频率）：
CPUID highest leaf : [16h]
Running as root : [YES]
MSR reads supported : [YES]
CPU pinning enabled : [YES]
CPU supports AVX2 : [YES]
CPU supports AVX-512: [YES]
cpuid = eax = 2, ebx = 266, ecx = 0, edx = 0
cpu: family = 6, model = 85, stepping = 4
tsc_freq = 3191.8 MHz (from calibration loop)
CPU brand string: Intel(R) Xeon(R) W-2104 CPU @ 3.20GHz
4 available CPUs: [0, 1, 2, 3]
4 physical cores: [0, 1, 2, 3]
Will test up to 1 CPUs
Cores | ID | Description | OVRLP1 | OVRLP2 | OVRLP3 | Mops | A/M-ratio | A/M-MHz | M/tsc-ratio
1 | pause_only | pause instruction | 1.000 | 1.000 | 1.000 | 2256 | 0.99 | 3173 | 1.00
1 | ucomis_clean | scalar ucomis (w/ vzeroupper) | 1.000 | 1.000 | 1.000 | 790 | 1.00 | 3192 | 1.00
1 | ucomis_dirty | scalar ucomis (no vzeroupper) | 1.000 | 1.000 | 1.000 | 466 | 0.88 | 2793 | 1.00
1 | scalar_iadd | Scalar integer adds | 1.000 | 1.000 | 1.000 | 3192 | 0.99 | 3165 | 1.00
1 | avx128_iadd | 128-bit integer serial adds | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx256_iadd | 256-bit integer serial adds | 1.000 | 1.000 | 1.000 | 2793 | 0.87 | 2793 | 1.00
1 | avx512_iadd | 512-bit integer adds | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_iadd_t | 128-bit integer parallel adds | 1.000 | 1.000 | 1.000 | 8380 | 0.88 | 2793 | 1.00
1 | avx256_iadd_t | 256-bit integer parallel adds | 1.000 | 1.000 | 1.000 | 8380 | 0.88 | 2793 | 1.00
1 | avx128_mov_sparse | 128-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx256_mov_sparse | 256-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx512_mov_sparse | 512-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 2794 | 0.87 | 2793 | 1.00
1 | avx128_merge_sparse | 128-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx256_merge_sparse | 256-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx512_merge_sparse | 512-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_vshift | 128-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx256_vshift | 256-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx512_vshift | 512-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_vshift_t | 128-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 5587 | 0.88 | 2793 | 1.00
1 | avx256_vshift_t | 256-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 5588 | 0.88 | 2793 | 1.00
1 | avx512_vshift_t | 512-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_imul | 128-bit integer muls | 1.000 | 1.000 | 1.000 | 559 | 0.88 | 2793 | 1.00
1 | avx256_imul | 256-bit integer muls | 1.000 | 1.000 | 1.000 | 559 | 0.88 | 2793 | 1.00
1 | avx512_imul | 512-bit integer muls | 1.000 | 1.000 | 1.000 | 559 | 0.88 | 2793 | 1.00
1 | avx128_fma_sparse | 128-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx256_fma_sparse | 256-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx512_fma_sparse | 512-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx128_fma | 128-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 698 | 0.88 | 2793 | 1.00
1 | avx256_fma | 256-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 698 | 0.87 | 2793 | 1.00
1 | avx512_fma | 512-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 698 | 0.88 | 2793 | 1.00
1 | avx128_fma_t | 128-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 4789 | 0.75 | 2394 | 1.00
1 | avx256_fma_t | 256-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 4790 | 0.75 | 2394 | 1.00
1 | avx512_fma_t | 512-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 2394 | 0.75 | 2394 | 1.00
1 | avx512_vpermw | 512-bit serial WORD permute | 1.000 | 1.000 | 1.000 | 466 | 0.88 | 2793 | 1.00
1 | avx512_vpermw_t | 512-bit parallel WORD permute | 1.000 | 1.000 | 1.000 | 1397 | 0.87 | 2793 | 1.00
1 | avx512_vpermd | 512-bit serial DWORD permute | 1.000 | 1.000 | 1.000 | 931 | 0.87 | 2793 | 1.00
1 | avx512_vpermd_t | 512-bit parallel DWORD permute | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
全速运行的唯一测试是标量整数加法，它根本不使用SSE/AVX寄存器，以及标量ucomis（w/vzeroupper），它在每次测试之前有一个显式的vzeroupper，因此不使用脏的Upper执行。
然后，我将脏指令更改为您感兴趣的vpcmpeqb k0，zmm0，[rsp]指令。新结果：
Cores | ID | Description | OVRLP1 | OVRLP2 | OVRLP3 | Mops | A/M-ratio | A/M-MHz | M/tsc-ratio
1 | pause_only | pause instruction | 1.000 | 1.000 | 1.000 | 2256 | 1.00 | 3192 | 1.00
1 | ucomis_clean | scalar ucomis (w/ vzeroupper) | 1.000 | 1.000 | 1.000 | 790 | 1.00 | 3192 | 1.00
1 | ucomis_dirty | scalar ucomis (no vzeroupper) | 1.000 | 1.000 | 1.000 | 790 | 1.00 | 3192 | 1.00
1 | scalar_iadd | Scalar integer adds | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx128_iadd | 128-bit integer serial adds | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3190 | 1.00
1 | avx256_iadd | 256-bit integer serial adds | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx512_iadd | 512-bit integer adds | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_iadd_t | 128-bit integer parallel adds | 1.000 | 1.000 | 1.000 | 9575 | 1.00 | 3192 | 1.00
1 | avx256_iadd_t | 256-bit integer parallel adds | 1.000 | 1.000 | 1.000 | 9577 | 1.00 | 3192 | 1.00
1 | avx128_mov_sparse | 128-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx256_mov_sparse | 256-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx512_mov_sparse | 512-bit reg-reg mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx128_merge_sparse | 128-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx256_merge_sparse | 256-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx512_merge_sparse | 512-bit reg-reg merge mov | 1.000 | 1.000 | 1.000 | 2793 | 0.88 | 2793 | 1.00
1 | avx128_vshift | 128-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx256_vshift | 256-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx512_vshift | 512-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_vshift_t | 128-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 6386 | 1.00 | 3192 | 1.00
1 | avx256_vshift_t | 256-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 6386 | 1.00 | 3192 | 1.00
1 | avx512_vshift_t | 512-bit variable shift (vpsrld) | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
1 | avx128_imul | 128-bit integer muls | 1.000 | 1.000 | 1.000 | 638 | 1.00 | 3192 | 1.00
1 | avx256_imul | 256-bit integer muls | 1.000 | 1.000 | 1.000 | 639 | 1.00 | 3192 | 1.00
1 | avx512_imul | 512-bit integer muls | 1.000 | 1.000 | 1.000 | 559 | 0.88 | 2793 | 1.00
1 | avx128_fma_sparse | 128-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx256_fma_sparse | 256-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 3193 | 1.00 | 3192 | 1.00
1 | avx512_fma_sparse | 512-bit 64-bit sparse FMAs | 1.000 | 1.000 | 1.000 | 2793 | 0.87 | 2793 | 1.00
1 | avx128_fma | 128-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 798 | 1.00 | 3192 | 1.00
1 | avx256_fma | 256-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 798 | 1.00 | 3192 | 1.00
1 | avx512_fma | 512-bit serial DP FMAs | 1.000 | 1.000 | 1.000 | 698 | 0.88 | 2793 | 1.00
1 | avx128_fma_t | 128-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 6384 | 1.00 | 3192 | 1.00
1 | avx256_fma_t | 256-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 5587 | 0.87 | 2793 | 1.00
1 | avx512_fma_t | 512-bit parallel DP FMAs | 1.000 | 1.000 | 1.000 | 2394 | 0.75 | 2394 | 1.00
1 | avx512_vpermw | 512-bit serial WORD permute | 1.000 | 1.000 | 1.000 | 466 | 0.87 | 2793 | 1.00
1 | avx512_vpermw_t | 512-bit parallel WORD permute | 1.000 | 1.000 | 1.000 | 1397 | 0.88 | 2793 | 1.00
1 | avx512_vpermd | 512-bit serial DWORD permute | 1.000 | 1.000 | 1.000 | 931 | 0.88 | 2793 | 1.00
1 | avx512_vpermd_t | 512-bit parallel DWORD permute | 1.000 | 1.000 | 1.000 | 2794 | 0.88 | 2793 | 1.00
大多数测试现在以全速运行。如预期的那样，仍在2.8 GHz（或在一种情况下，并行512位FMA为2.4 GHz）下运行的是那些实际使用512位向量，或使用256位向量和像FMA一样的重浮点指令的。
-
我对同步块有一些疑问。在提问之前，我想分享另一个相关帖子链接的答案，以回答相关问题。我引用彼得·劳里的同一个答案。 > <块引号> 同步确保您对数据有一致的视图。这意味着您将读取最新值，其他缓存将获得最新值。缓存足够智能，可以通过特殊总线相互通信（JLS不需要，但允许）该总线意味着它不必触摸主存储器即可获得一致的视图。 如果您只使用同步，则不需要Volatile。如果您有一个非常简单的操作，而同步
-
是否可以同时从套接字读取和写入？我有一个连续读取套接字的线程。由于只有一个线程从套接字读取，因此读取操作是线程安全的。现在我有很多线程（比如 100 个）写入套接字。因此，很明显，我必须通过做这样的事情来使写入操作线程安全， 现在我有一个线程不断调用readMessage()函数(在while循环中)。据我所知，如果套接字上没有要读取的消息，语句< code > inputstream . rea
-
我试图找到/创建一个位旋转算法，该算法在-bit-count位掩码中生成s的所有
-
实地址模式下的寄存器集合包括8086定义的所有寄存器，加上80386新引入的寄存器：FS, GS, 调试寄存器，控制寄存器，和测试寄存器。可以显式的使用段寄存器FS和GS作为操作数，而且可以使用新引入的段－重写前缀来利用FS和GS来计算地址。指令可以利用操作数长度前缀来使用32位操作数。 保护模式下操作，检查80386选择符和描述符的指令导致未定义操作码陷阱（中断6）；这些指令包括：VERR, V
-
问题内容： 我对同步块几乎没有疑问。 1. > 同步可确保您拥有一致的数据视图。这意味着您将读取最新值，而其他缓存将获得最新值。高速缓存足够智能，可以通过特殊总线相互通信（这不是JLS所必需的，但允许）。该总线意味着不必触摸主内存即可获得一致的视图。 如果仅使用同步，则不需要volatile。如果您有一个非常简单的操作（对于同步操作可能会过分杀伤），则波动性很有用。 参考上面，我有以下三个问题：
-
问题内容： 我想知道，在关闭阅读器之后，是否需要关闭InputStream？ 问题答案： 不，您不必。 由于Java中用于流的装饰器方法可以通过将新流或读取器附加到其他流上来构建新流或读取器，因此实现将自动对其进行处理。 如果查看其来源，则会看到： 因此，关闭操作实际上关闭了底层的流读取器。 编辑：我想确保关闭也可以在输入流上工作，请继续关注。 签入 在调用sd的close时调用。