x86-64 汇编的性能优化 - 对齐和分支预测

我目前正在编写一些 C99 标准库字符串函数的高度优化版本，例如strlen(), memset()等，使用带有 SSE-2 指令的 x86-64 汇编。

到目前为止，我已经在性能方面取得了出色的结果，但当我尝试进一步优化时，有时会出现奇怪的行为。

例如，添加甚至删除一些简单的指令，或者简单地重新组织一些与跳转一起使用的本地标签会完全降低整体性能。就代码而言，绝对没有理由。

所以我的猜测是，代码对齐和/或分支预测存在一些问题。

我知道，即使采用相同的架构（x86-64），不同的CPU也有不同的分支预测算法。

但是，在 x86-64 上进行高性能开发时，是否有一些关于代码对齐和分支预测的一般建议？

特别是，关于对齐，我是否应该确保跳转指令使用的所有标签都在 DWORD 上对齐？

_func:
    ; ... Some code ...
    test rax, rax
    jz   .label
    ; ... Some code ...
    ret
    .label:
        ; ... Some code ...
        ret

在前面的代码中，我应该在之前使用对齐指令吗.label:, like:

align 4
.label:

如果是这样，在使用 SSE-2 时对齐 DWORD 是否足够？

关于分支预测，是否有一种“首选”方式来组织跳转指令使用的标签，以帮助 CPU，或者当今的 CPU 是否足够智能，可以在运行时通过计算分支发生的次数来确定这一点？

EDIT

好的，这是一个具体的例子 - 这是开始strlen()使用 SSE-2：

_strlen64_sse2:
    mov         rsi,    rdi
    and         rdi,    -16
    pxor        xmm0,   xmm0
    pcmpeqb     xmm0,   [ rdi ]
    pmovmskb    rdx,    xmm0
    ; ...

使用 1000 个字符串运行 10'000'000 次大约需要 0.48 秒，这还不错。
但它不检查 NULL 字符串输入。显然，我将添加一个简单的检查：

_strlen64_sse2:
    test       rdi,    rdi
    jz          .null
    ; ...

同样的测试，现在运行时间为 0.59 秒。但是如果我在检查后对齐代码：

_strlen64_sse2:
    test       rdi,    rdi
    jz          .null
    align      8
    ; ...

原来的表演又回来了。我使用 8 进行对齐，因为 4 不会改变任何内容。
谁能解释一下这一点，并就何时对齐或不对齐代码部分提供一些建议？

EDIT 2

当然，这并不像对齐每个分支目标那么简单。如果我这样做，性能通常会变得更糟，除非像上面这样的某些特定情况。

对齐优化

1. Use .p2align <abs-expr> <abs-expr> <abs-expr>代替align.

使用 3 个参数进行细粒度控制

• param1- 与什么边界对齐。
• param2- 用什么（零或NOPs).
• param3- 如果填充超出指定的字节数，则不对齐。

2. 将常用代码块的开头与缓存行大小边界对齐。

• 这增加了整个代码块位于单个缓存行中的机会。一旦加载到 L1 高速缓存中，就可以完全运行，无需访问 RAM 来获取指令。这对于具有大量迭代的循环非常有益。

3.使用多字节NOPs 用于填充到减少执行时间NOPs.

  /* nop */
  static const char nop_1[] = { 0x90 };

  /* xchg %ax,%ax */
  static const char nop_2[] = { 0x66, 0x90 };

  /* nopl (%[re]ax) */
  static const char nop_3[] = { 0x0f, 0x1f, 0x00 };

  /* nopl 0(%[re]ax) */
  static const char nop_4[] = { 0x0f, 0x1f, 0x40, 0x00 };

  /* nopl 0(%[re]ax,%[re]ax,1) */
  static const char nop_5[] = { 0x0f, 0x1f, 0x44, 0x00, 0x00 };

  /* nopw 0(%[re]ax,%[re]ax,1) */
  static const char nop_6[] = { 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00 };

  /* nopl 0L(%[re]ax) */
  static const char nop_7[] = { 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00 };

  /* nopl 0L(%[re]ax,%[re]ax,1) */
  static const char nop_8[] =
    { 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00};

  /* nopw 0L(%[re]ax,%[re]ax,1) */
  static const char nop_9[] =
    { 0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 };

  /* nopw %cs:0L(%[re]ax,%[re]ax,1) */
  static const char nop_10[] =
    { 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 };

(upto 10byte NOPs 代表 x86。来源binutils-2.2.3.)

分支预测优化

_{Lot of variations between x86_64 micro-architectures/generations. However a common set of guidelines that are applicable for all of them can be summarised as follows. Reference : Section 3 of Agner Fog's x86 micro-architecture manual.}

1. 展开循环以避免迭代计数稍高。

• 循环检测逻辑保证仅适用于具有< 64迭代。这是因为如果分支指令单向运行，则该分支指令将被识别为具有循环行为n-1次，然后走另一条路1时间，对于任何n最多 64 个。

  这并不真正适用于 Haswell 及更高版本中的预测器，它们使用 TAGE 预测器，并且没有针对特定分支的专用循环检测逻辑。在 Skylake 上，对于没有其他分支的紧密外循环内的内循环来说，迭代计数约为 23 可能是最坏的情况：内循环的退出大多数时候都会错误预测，但行程计数非常低，因此经常发生。展开可以通过缩短模式来提供帮助，但对于非常高的循环行程计数，最终的单个错误预测会在多次行程中摊销，并且需要不合理的展开量才能对此采取任何措施。

2.坚持近跳/短跳。

• 无法预测远跳转，即管道总是在远跳转到新代码段 (CS:RIP) 时停止。无论如何，基本上没有理由使用远跳，所以这基本上是不相关的。

  在大多数 CPU 上，通常可以预测具有任意 64 位绝对地址的间接跳转。

  但是，当目标距离超过 4GB 时，Silvermont（Intel 的低功耗 CPU）在预测间接跳转方面存在一些限制，因此通过在低 32 位虚拟地址空间中加载/映射可执行文件和共享库可以避免这种情况的发生。 。例如在 GNU/Linux 上通过设置环境变量LD_PREFER_MAP_32BIT_EXEC。有关更多信息，请参阅英特尔的优化手册。