为什么AMD-CPU有如此愚蠢的暂停计时

Question

我已经为C++开发了一个类似于Java的监视器对象，并做了一些改进。主要的改进是不仅有一个用于锁定和解锁的自旋循环，而且还有一个用于等待事件的自旋循环。在这种情况下，您不必锁定互斥锁，而是在wait_poll函数上提供一个谓词，代码反复尝试锁定互斥锁轮询，如果可以锁定互斥锁，则调用返回(或移动)一对bool和result-type的谓词。

等待内核中的信号量和/或事件对象(Win32)很容易占用1.000到10.000个时钟周期，即使当调用立即返回时也是如此，因为之前已经设置了信号量或事件。所以必须有一个旋转计数，与这个等待积分有合理的关系，f.e.旋转在内核中花费的最小间隔的十分之一。

对于我的monitor-object，我从glibc中获取了spincount重新计算算法。我还使用了PAUSE-指令。但是我发现在我的CPU (TR3900X)上暂停指令太快了。平均约为0.78纳秒。在Intel-CPU上，它更合理，大约为30 On。

代码如下：

#include <iostream>
#include <chrono>
#include <cstddef>
#include <cstdint>
#include <immintrin.h>

using namespace std;
using namespace chrono;

int main( int argc, char **argv )
{
    static uint64_t const PAUSE_ROUNDS = 1'000'000'000;
    auto start = high_resolution_clock::now();
    for( uint64_t i = PAUSE_ROUNDS; i; --i )
        _mm_pause();
    double ns = (int64_t)duration_cast<nanoseconds>( high_resolution_clock::now() - start ).count() / (double)PAUSE_ROUNDS;
    cout << ns << endl;
}

为什么AMD采取了如此愚蠢的暂停时间？PAUSE用于自旋-等待-循环，应该与缓存内容翻转到不同的核心并返回所需的时间非常接近。

Answer 1

，但是我发现在我的CPU (TR3900X)上暂停指令太快了。平均约为0.78纳秒。在Intel-CPU上，它更合理，大约为30 On。

pause指令与时间没有任何关系，也不打算用作时间延迟。

pause的作用是防止CPU浪费资源(投机性地)并行执行循环的多次迭代；这在超线程情况下特别有用，在这种情况下，内核中的不同逻辑处理器可以使用这些资源，但也有助于在条件发生变化时缩短退出循环所需的时间(因为在条件发生变化之前不会有"N次迭代“的指令排队)。

鉴于此，对于可能同时有200条指令的极其复杂的CPU，pause本身可能会立即发生，但会导致"200个周期长“的流水线泡沫；而对于极其简单的CPU (”按顺序“，没有推测执行)，pause可能/应该什么都不做(被视为nop)。

PAUSE用于自旋-等待-循环，应该与缓存内容翻转到不同的核心并返回所需的时间非常接近。

不是的。假设高速缓存线在不同的CPU的高速缓存中处于“已修改”状态，并且pause之后的指令类似于"cmp [lock],0“，它会使CPU尝试将高速缓存线置于”共享“状态。在pause之后，但在尝试将缓存线置于“共享”状态之前，CPU应该浪费多长时间来无缘无故地无所作为？

注意:如果你确实需要一个很小的时间延迟，那么你应该看看umwait指令。你不需要时间延迟--你想要一个超时(例如，“使用pause旋转；直到rdtsc说已经过了一定的时间”)。为此，我很想把它分成一个内部循环，执行"pause并检查条件N次“，然后执行一个外部循环，执行”如果时间限制还没有过期，就重试内部循环“。