optimization - "the optimized delay"是一个神话还是真实的？

Question

时不时你会听到一些故事，这些故事旨在说明某人在某件事上有多擅长，有时你会听到这个人如何热衷于代码优化，以至于他优化了他的延迟循环。

因为这听起来确实是一件奇怪的事情，因为启动“计时器中断”而不是优化的繁忙等待要好得多，没有人会告诉你优化黑客的名字。

这让我想知道这是一个都市神话还是真实的？

你说什么，现实还是虚构？

谢谢约翰

<小时/>

更新:听起来 ShuggyCoUk 似乎有所发现，不知道我们能否找到一个例子。

更新:稍微澄清一下，这个问题是关于“延迟”函数本身以及如何实现的，而不是如何调用它以及在哪里调用它。目的是什么，以及该系统如何变得更好。

更新:这不是神话，那些家伙似乎存在

谢谢舒吉库克

Answer 1

这不仅仅是一个事实核心......

自旋等待比基于信号的中断或让出要好得多。

• 您可以用一些吞吐量来换取大幅减少的延迟。
  • 通常这对于操作系统本身来说至关重要。
• 您可以自由地执行中断处理程序中不可能执行的操作
  • 例如内存分配。
• 您可以对等待时间间隔进行更细粒度的控制，因为您基本上可以测量周期计数。

然而，旋转等待很难正确执行。

• 如果可以的话，您应该使用正确的闲置说明，其中:
  • 可以关闭部分核心的电源，改善功耗/散热，甚至允许其他核心运行得更快。
  • 在基于超线程的 CPU 中，您allow the other logical thread to use the full CPU pipeline while you spin 。
  • 您可能认为的指令是无操作，可能会导致 CPU 通过超标量执行单元乱序执行它们。生成的代码可能会出现不可预见的无序伪像，从而迫使 CPU 在不必要的停顿和内存屏障方面付出大量努力。

这就是为什么在大多数情况下你让别人为你编写旋转等待循环..

• 在 Linux 中，有 cpu_relax macro

  • 在 ARM 上这是barrier()
  • 在 x86 上，这是rep_nop()

• 在 Windows 中，有 YieldProcessor

  • 可通过 Thread.SpinWait 在 .Net 中访问

• OS X eschews providing a standard implementation除非你在内核中

  • 参见this document并注意它鼓励仅使用 lck_spin_t

关于使用 PAUSE 进行旋转等待的一些引用:

• PostGresSQL
• Linux
  • 另请参阅注释，由于功耗降低，这在非 P4 上也更好