Skylake可以在一个周期执行多少个1字节NOP

时间:2017-07-11 17:24:52

标签: assembly optimization x86 alignment nop

我将分支目标与NOP对齐,有时CPU执行这些NOP,最多15个NOP。 Skylake可以在一个周期内执行多少个1字节NOP?其他与AMD兼容的处理器如何?我不仅对Skylake感兴趣,而且对其他微型网站也感兴趣。执行一系列15个NOP可能需要多少个周期?我想知道增加这些NOP的额外代码大小和额外执行时间是否物有所值。每当我编写align指令时,这不是我自动添加这些NOP而是自动汇编程序。

更新:我已将其设置为自动插入多字节NOP

2 个答案:

答案 0 :(得分:2)

另见Cody关于我要遗漏的许多好东西的答案,因为他已经覆盖了它。

绝不使用多个1字节NOP 。所有装配工都有办法获得长时间的NOP;见下文。

15个NOP以每个时钟通常的4个时钟发出3.75c,但如果它在那个时候在长依赖链上遇到瓶颈,可能根本不会减慢你的代码速度。他们一直占用ROB的空间直到退休。他们唯一不做的就是使用执行端口。关键是,CPU性能不是附加的。你不能只说“这需要5个周期,这需要3个,所以它们一起需要8个”。无序执行的重点是与周围的代码重叠。

许多1字节短NOP对SnB系列的影响更大的是它们倾向于溢出每个对齐的32B x86代码块的3行的uop-cache限制。这意味着整个32B块总是必须从解码器运行,而不是uop缓存或循环缓冲区。 (循环缓冲区仅适用于在uop缓存中具有所有uop的循环。)

实际执行的行中最多只能有2个NOP,只有当你需要填充超过10B或15B或其他东西时。 (有些CPU在解码具有很多前缀的指令时表现非常糟糕,因此对于实际执行它的NOP,最好不要将前缀重复到15B(最大x86指令长度)。

YASM默认制作长NOP。对于NASM,请使用默认情况下未启用的the smartalign standard macro package。它迫使你选择NOP策略。

%use smartalign
ALIGNMODE p6, 32     ;  p6 NOP strategy, and jump over the NOPs only if they're 32B or larger.

IDK,如果32是最佳的。此外,要注意最长的NOP可能会使用很多前缀并在Silvermont或AMD 上慢慢解码。检查NASM手册以了解其他模式。

GNU汇编程序的.p2align指令为您提供了一些条件行为.p2align 4,,10将对齐到16(1<<<<<<<<<<<<<<< 4),但仅当它跳过10个字节或少。 (空的第二个arg表示填充符是NOP,而2的幂对齐名称是因为普通.align在某些平台上是2的幂,但在其他平台上是字节数。 gcc经常在循环顶部之前发出这个:

  .p2align 4,,10 
  .p2align 3
.L7:

所以你总是得到8字节对齐(无条件.p2align 3),但也可能是16,除非浪费超过10B。首先放置较大的对齐对于避免例如1字节NOP,然后是8字节NOP,而不是单个9字节NOP。

可能可以使用NASM宏实现此功能。

缺少任何汇编程序的功能(AFAIK)

  • 通过使用更长的编码(例如,imm32而不是imm8或不需要的REX前缀)来填充前面的指令的指令,以在没有NOP的情况下实现所需的对齐。
  • 基于以下指令长度的智能条件填充,如果在下一个16B或32B边界之前可以解码4条指令,则不填充。

解码瓶颈的对齐通常不再那么重要,因为调整它通常涉及手动汇编/反汇编/编辑循环,如果前面的代码发生变化,必须再次查看。

特别是如果您对一组有限的CPU进行调整,请进行测试,如果没有找到性能优势,请进行测试。在很多情况下,尤其是对于具有uop缓存和/或循环缓冲区的CPU,可以不在函数内对齐分支目标,甚至是循环。

由于变化对齐导致的一些性能变化是它在分支预测缓存中使不同的分支相互别名。即使uop缓存完美运行,这种次要的微妙效果仍然存在并且从uop缓存中获取大部分空行没有前端瓶颈。

另见Performance optimisations of x86-64 assembly - Alignment and branch prediction

答案 1 :(得分:2)

Skylake通常可以在一个周期内执行四个单字节nops 。至少回到Sandy Bridge(以下简称SnB)微架构时,情况确实如此。

Skylake和其他人回到SnB,一般也能在一个周期内执行四个长于一个字节的nop,除非它们长到跑到前端限制。

现有的答案更加完整,并解释了为什么你可能不想使用这样的单字节nop指令,所以我不会添加更多,但很高兴有一个答案可以回答我认为,标题问题很清楚。