流内在会降低性能答案

【问题标题】：Stream intrinsic degrades performance流内在会降低性能
【发布时间】：2014-02-08 00:43:45
【问题描述】：

我正在使用 _mm_stream_ps 内在函数，但在理解它的性能方面遇到了一些麻烦。

这是我正在使用的代码 sn-p... 流版本：

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <omp.h>

#include <immintrin.h>

#define NUM_ELEMENTS 10000000L

static void copy_temporal(float* restrict x, float* restrict y)
{
   for(uint64_t i = 0; i < NUM_ELEMENTS/2; ++i){
      _mm_store_ps(y,_mm_load_ps(x));
      _mm_store_ps(y+4,_mm_load_ps(x+4));
      x+=8;
      y+=8;
   }
}
static void copy_nontemporal(float* restrict x, float* restrict y)
{
   for(uint64_t i = 0; i < NUM_ELEMENTS/2; ++i){
      _mm_stream_ps(y,_mm_load_ps(x));
      _mm_stream_ps(y+4,_mm_load_ps(x+4));
      x+=8;
      y+=8;
   }
}

int main(int argc, char** argv)
{
   uint64_t sizeX = sizeof(float) * 4 * NUM_ELEMENTS;
   float *x = (float*) _mm_malloc(sizeX,32);
   float *y = (float*) _mm_malloc(sizeX,32);

   //initialization
   for(uint64_t i = 0 ; i < 4 * NUM_ELEMENTS; ++i){
      x[i] = (float)rand()/RAND_MAX;
      y[i] = 0;
   }

   printf("%g MB allocated\n",(2 * sizeX)/1024.0/1024.0); 

   double start = omp_get_wtime();
   copy_nontemporal(x, y);
   double time = omp_get_wtime() - start;
   printf("Bandwidth (non-temporal): %g GB/s\n",((3 * sizeX)/1024.0/1024.0/1024.0)/time);

   start = omp_get_wtime();
   copy_temporal(x, y);
   time = omp_get_wtime() - start;
   printf("Bandwidth: %g GB/s\n",((3 * sizeX)/1024.0/1024.0/1024.0)/time);

   _mm_free(x);
   _mm_free(y);

   return 0;
}

性能结果：

2.3 GHz Core i7 (I7-3615QM) (Laptop):
    305.176 MB allocated
    Bandwidth (non-temporal): 24.2242 GB/s
    Bandwidth: 21.4136 GB/s

Xeon(R) CPU E5-2650 0 @ 2.00GHz (cluster (exclusive job)):
    305.176 MB allocated
    Bandwidth (non-temporal): 8.33133 GB/s
    Bandwidth: 8.20684 GB/s

真正让我感到困惑的是，如果我使用非对齐的加载和存储（即 storeu_ps/loadu_ps），我会看到更好的性能 - 在 Xeon CPU（不是在我的笔记本电脑上）：

305.176 MB allocated
Bandwidth (non-temporal): 8.30105 GB/s
Bandwidth: 12.7056 GB/s

由于 y 的冗余负载，我希望流版本比非流版本更快。但是，测量表明流版本实际上比非流版本慢两倍。

你对此有什么解释吗？

使用的编译器：Intel 14.0.1；编译器标志：-O3 -restrict -xAVX；使用的 CPU：Intel Xeon E5-2650；

谢谢。

【问题讨论】：

无需展开循环。循环展开只对依赖链有用，没有依赖链。 CPU 可以为您解决这个问题。但我有个问题。您的带宽计算中的 3 系数是多少？
两次读取+一次写入。尽管非临时版本只读取一次，但我保留了 3 的因子以使比较更简单。

标签： assembly vectorization sse intrinsics avx

【解决方案1】：

流变体创建流水线突发写入直接到 DRAM。速度应该与您的 DRAM 的速度大致匹配。标准存储写入缓存（但如果数据尚未在缓存中，它会先将其读入缓存）。如果数据已经在缓存中，则标准存储以缓存写入的速度运行。通常，使用流方法，大小远大于最后一级缓存大小的写入要快得多。使用标准存储时，小型写入通常更快。尝试使用几 GB 的缓冲区大小运行测试。流方法应该更快。

这是一个可以证明的基准：

#define __USE_MINGW_ANSI_STDIO 1
#include <stdlib.h>
#include <intrin.h>
#include <windows.h>
#include <stdio.h>
#include <stdint.h>

//-----------------------------------------------------------------------------
//
//  queryPerformanceCounter - similar to QueryPerformanceCounter, but returns
//                            count directly.

uint64_t queryPerformanceCounter (void)
    {
    LARGE_INTEGER int64;
    QueryPerformanceCounter (&int64);
    return int64.QuadPart;
    }

//-----------------------------------------------------------------------------
//
// queryPerformanceFrequency - same as QueryPerformanceFrequency, but returns  count direcly.

uint64_t queryPerformanceFrequency (void)
    {
    LARGE_INTEGER int64;

    QueryPerformanceFrequency (&int64);
    return int64.QuadPart;
    }

//---------------------------------------------------------------------------

static void testNontemporal (float *x, float *y, uint64_t numberOfVectors)
    {
    uint64_t i;
    for(i = 0; i < numberOfVectors / 2; ++i)
        {
        _mm_stream_ps(y,_mm_load_ps(x));
        _mm_stream_ps(y+4,_mm_load_ps(x+4));
        y+=8; x+=8;
        }
    }

//---------------------------------------------------------------------------

static void testTemporal (float *x, float *y, uint64_t numberOfVectors)
    {
    uint64_t i;
    for(i = 0; i < numberOfVectors / 2; ++i)
        {
        _mm_store_ps(y,_mm_load_ps(x));
        _mm_store_ps(y+4,_mm_load_ps(x+4));
        y+=8; x+=8;
        }
    }

//---------------------------------------------------------------------------

static void runtests (int nonTemporal)
    {
    uint64_t startCount, elapsed, index;
    float *x, *y;
    uint64_t numberOfBytes = 400 * 0x100000ull;
    uint64_t numberOfFloats = numberOfBytes / sizeof *x;
    uint64_t numberOfVectors = numberOfFloats / 4;
    double gbPerSecond;

    x = _mm_malloc (numberOfBytes, 32);
    y = _mm_malloc (numberOfBytes, 32);
    if (x == NULL || y == NULL) exit (1);

    // put valid floating point data into the source buffer
    // to avoid performance penalty
    for (index = 0; index < numberOfFloats; index++)
        x [index] = (float) index, y [index] = 0;

    startCount = queryPerformanceCounter ();
    if (nonTemporal)
        testNontemporal (x, y, numberOfVectors);
    else
        testTemporal (x, y, numberOfVectors);
    elapsed = queryPerformanceCounter () - startCount;
    gbPerSecond = (double) numberOfBytes / 0x40000000 * queryPerformanceFrequency () / elapsed;
    printf ("%.2f GB/s\n", gbPerSecond);
    _mm_free (x);
    _mm_free (y);
    }

//---------------------------------------------------------------------------

int main (void)
    {
    // raise our priority to increase measurement accuracy
    SetPriorityClass (GetCurrentProcess (), REALTIME_PRIORITY_CLASS);

    printf ("using temporal stores\n");
    runtests (0);
    printf ("using non-temporal stores\n");
    runtests (1);
    return 0;
    }

//---------------------------------------------------------------------------

英特尔酷睿 i7-2600K 的输出：

using temporal stores
5.57 GB/s
using non-temporal stores
8.35 GB/s

【讨论】：

感谢您的回复。我已经在使用大小为 400MB 的缓冲区（即比我系统中的任何缓存都大得多）。此外，为了读取一些硬件计数器，我已经对代码进行了检测，结果是确凿的（即使用 stream_ps 导致更少的 l2 写入未命中）。但是，我仍然无法解释这两个版本之间的巨大性能差异。
我将添加一个示例基准测试，尝试显示大缓冲区的非时间（流）优势。这有点快和肮脏，但我认为是正确的。使用了非便携式 (Windows) 计时功能。
我已经更新了我的原始帖子，但我无法重现您的结果（即使我将您的代码移植到 Linux，结果仍然相同）。你知道为什么会这样吗？此外，您是否解释了为什么非对齐版本更快？这实际上可能指向真正的问题，因为流确实需要对齐。
@ScottD，我在 MSVC 中运行了你的测试。运行它们几次，结果来回交换。两种方法在不确定性范围内的速度相同。
@Z，您使用的是优化的发布版本还是调试版本？我在运行调试版本时得到了您所描述的内容。但是发布版本（或命令行 cl -Ox stream.c）按预期工作。

【解决方案2】：

AFAIK，非临时存储从所有缓存中删除目标缓存行。如果在它自然掉线之前再次触摸它，你就输得很惨。

【讨论】：

我想说这取决于所讨论缓冲区的大小，但您对 ScottD 的评论表明它们非常大。在这一点上，我不确定发生了什么。您可以尝试各种方法，例如注释掉 #pragmas、不使用 -xAVX 进行编译等，寻找常规存储和非临时存储之间性能比率的变化。

【解决方案3】：

正如 ScottD 所指出的，问题的答案在于生成的汇编代码。显然，英特尔编译器足够聪明，可以检测访问模式并自动生成非临时负载，即使是临时版本。

这是编译器生成的临时版本的汇编代码：

..___tag_value___Z13copy_temporalPfS_.35:                       #
        xor       edx, edx                                      #22.4
        xor       eax, eax                                      #
..B2.2:                         # Preds ..B2.2 ..B2.1
        vmovups   xmm0, XMMWORD PTR [rax+rdi]                   #23.34
        inc       rdx                                           #22.4
        vmovntps  XMMWORD PTR [rax+rsi], xmm0                   #23.20
        vmovups   xmm1, XMMWORD PTR [16+rax+rdi]                #24.36
        vmovntps  XMMWORD PTR [16+rax+rsi], xmm1                #24.20
        vmovups   xmm2, XMMWORD PTR [32+rax+rdi]                #23.34
        vmovntps  XMMWORD PTR [32+rax+rsi], xmm2                #23.20
        vmovups   xmm3, XMMWORD PTR [48+rax+rdi]                #24.36
        vmovntps  XMMWORD PTR [48+rax+rsi], xmm3                #24.20
        add       rax, 64                                       #22.4
        cmp       rdx, 5000000                                  #22.4
        jb        ..B2.2        # Prob 99%                      #22.4

剩下的问题如下：

为什么对于 CPU E5-2650（见上文），非对齐、临时版本的性能优于非临时版本。我已经查看了生成的汇编代码，编译器确实生成了 vmovups 指令（由于不存在对齐）。

【讨论】：

如果 ICC 做的事情与你所说的不同，我会很失望。如果它以您想要的方式实现它们，我会更喜欢。