为什么std :: fill（0）比std :: fill（1）慢？

我在一个系统std::fill上观察到，与恒定值或动态值相比，将恒定值std::vector<int>设置为大时显着且始终较慢：01

5.8 GiB /秒和7.5 GiB /秒

但是，对于较小的数据，结果会有所不同，但fill(0)速度更快：

如果有多个线程，则在4 GiB数据大小下，fill(1)斜率更高，但峰值要低得多fill(0)（51 GiB / s与90 GiB / s）：

这就提出了第二个问题，即为什么峰值带宽 fill(1)这么低。

为此的测试系统是双插槽Intel Xeon CPU E5-2680 v3，设置为2.5 GHz（通过/sys/cpufreq），带有8x16 GiB DDR4-2133。我使用GCC 6.1.0（-O3）和Intel编译器17.0.1（-fast）进行了测试，两者均得到相同的结果。GOMP_CPU_AFFINITY=0,12,1,13,2,14,3,15,4,16,5,17,6,18,7,19,8,20,9,21,10,22,11,23被设定。Strem / add / 24线程在系统上的速度为85 GiB / s。

我能够在不同的Haswell双套接字服务器系统上重现这种效果，但在任何其他体系结构上均无法重现。例如，在Sandy Bridge EP上，内存性能是相同的，而在高速缓存fill(0)中则要快得多。

这是要重现的代码：

#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <omp.h>
#include <vector>

using value = int;
using vector = std::vector<value>;

constexpr size_t write_size = 8ll * 1024 * 1024 * 1024;
constexpr size_t max_data_size = 4ll * 1024 * 1024 * 1024;

void __attribute__((noinline)) fill0(vector& v) {
    std::fill(v.begin(), v.end(), 0);
}

void __attribute__((noinline)) fill1(vector& v) {
    std::fill(v.begin(), v.end(), 1);
}

void bench(size_t data_size, int nthreads) {
#pragma omp parallel num_threads(nthreads)
    {
        vector v(data_size / (sizeof(value) * nthreads));
        auto repeat = write_size / data_size;
#pragma omp barrier
        auto t0 = omp_get_wtime();
        for (auto r = 0; r < repeat; r++)
            fill0(v);
#pragma omp barrier
        auto t1 = omp_get_wtime();
        for (auto r = 0; r < repeat; r++)
            fill1(v);
#pragma omp barrier
        auto t2 = omp_get_wtime();
#pragma omp master
        std::cout << data_size << ", " << nthreads << ", " << write_size / (t1 - t0) << ", "
                  << write_size / (t2 - t1) << "\n";
    }
}

int main(int argc, const char* argv[]) {
    std::cout << "size,nthreads,fill0,fill1\n";
    for (size_t bytes = 1024; bytes <= max_data_size; bytes *= 2) {
        bench(bytes, 1);
    }
    for (size_t bytes = 1024; bytes <= max_data_size; bytes *= 2) {
        bench(bytes, omp_get_max_threads());
    }
    for (int nthreads = 1; nthreads <= omp_get_max_threads(); nthreads++) {
        bench(max_data_size, nthreads);
    }
}

提出的结果用编制g++ fillbench.cpp -O3 -o fillbench_gcc -fopenmp。

从您的问题+答案中的编译器生成的asm：

• fill(0)是一个ERMSBrep stosb，它将在优化的微码循环中使用256b存储器。（如果缓冲区对齐，则效果最好，可能至少为32B或64B）。

• fill(1)是一个简单的128位movaps向量存储循环。每个内核时钟周期只能执行一个存储，而不论宽度如何（最大256b AVX）。因此128b个存储区只能填充Haswell L1D高速缓存写入带宽的一半。 这就是为什么fill(0)高达〜32kiB的缓冲区快约2倍的原因。编译-march=haswell或-march=native修复。

  Haswell几乎无法跟上循环开销，但是即使它根本没有展开，它仍然可以每个时钟运行1个存储。但是，由于每个时钟有4个融合域uops，所以很多填充器会占用乱序窗口中的空间。某些展开操作可能会使TLB遗漏开始更远地解决存储发生的地方，因为存储地址的吞吐量比存储数据的吞吐量要大。对于适合L1D的缓冲区，展开可能有助于弥补ERMSB和此向量循环之间的其余差异。（对该问题的评论说，这-march=native仅对fill(1)L1有帮助。）

需要注意的是rep movsd（这可能被用来实现fill(1)的int元素）将可能执行相同的rep stosb上的Haswell。尽管只有官方文档才能保证ERMSB快速提供rep stosb（但不能保证rep stosd），但支持ERMSB的实际CPU仍使用类似的高效微代码rep stosd。关于IvyBridge可能存在一些疑问，也许只是b速度很快。参见@BeeOnRope的出色ERMSB答案更新，。

gcc有一些针对字符串操作的x86调整选项（例如-mstringop-strategy=alg和-mmemset-strategy=strategy），但IDK（如果有的话）会让它实际发送rep movsd给fill(1)。可能不是，因为我假设代码以循环而不是a开头memset。

如果有多个线程，则在4 GiB数据大小下，fill（1）会显示出较高的斜率，但会比fill（0）达到更低的峰值（51 GiB / s与90 GiB / s）：

正常movaps存储到冷缓存行会触发“读取所有权”（RFO）。movaps写入前16个字节时，大量的实际DRAM带宽用于从内存读取缓存行。ERMSB存储对其存储使用no-RFO协议，因此内存控制器仅在写入。（除了其他读取，例如页表，即使在L3缓存中也没有页面遍历丢失，并且在中断处理程序中或其他任何原因可能导致某些负载丢失）。

@BeeOnRope在评论中解释说，常规RFO存储与ERMSB使用的RFO规避协议之间的差异在服务器CPU上某些缓冲区大小范围内存在不利之处，其中非核心/ L3缓存中存在高延迟。 另请参阅链接的ERMSB答案，以获取有关RFO与非RFO的更多信息，以及在多核Intel CPU中非核（L3 /内存）的高延迟是单核带宽的问题。

movntps（_mm_stream_ps()）存储是弱排序的，因此它们可以绕过高速缓存并一次直接进入整个高速缓存行的内存，而无需将高速缓存行读入L1D。 movntps避免RFO，就像rep stos那样。（rep stos商店可以相互重新排序，但不能超出指令范围。）

您movntps在最新答案中得到的结果令人惊讶。
对于具有大缓冲区的单线程，您的结果是movnt>>常规RFO> ERMSB。因此，这两种非RFO方法位于普通旧商店的相对两侧实在很奇怪，而ERMSB远非最佳。我目前对此没有任何解释。（欢迎编辑提供解释和充分的证据）。

如我们预期的那样，movnt允许多个线程达到较高的聚合存储带宽，例如ERMSB。 movnt总是先进入行填充缓冲区，然后再进入内存，因此对于适合高速缓存的缓冲区大小，它要慢得多。每个时钟一个128b的向量足以轻松将单个内核的no-RFO带宽饱和到DRAM。当存储CPU绑定的AVX 256b矢量化计算的结果时（即，仅当它节省了解包到128b的麻烦时vmovntps ymm），可能（256b）只是vmovntps xmm（128b）相对（128b）的可衡量的优势。

movnti 带宽之所以低，是因为每个时钟以1个存储uop的4B块瓶颈存储，从而将数据添加到行填充缓冲区，而不是将这些行已满的缓冲区发送到DRAM（直到您有足够的线程来饱和内存带宽）。

@osgx在评论中发布了一些有趣的链接：

• Agner Fog的asm优化指南，说明表和Microarch指南：http：//agner.org/optimize/

• 英特尔优化指南：http : //www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf。

• NUMA监听：http : //frankdenneman.nl/2016/07/11/numa-deep-dive-part-3-cache-coherency/

• https://software.intel.com/zh-CN/articles/intelr-memory-latency-checker
• 英特尔Haswell-EP架构的缓存一致性协议和内存性能

另请参阅 x86 标签Wiki。

我将分享我的初步结果，希望鼓励更详细的答案。我只是觉得这本身就是问题的一部分。

编译器优化 fill(0)为一个内部memset。它不能对进行相同的操作fill(1)，因为它memset仅适用于字节。

具体来说，glibcs__memset_avx2和glibcs__intel_avx_rep_memset都通过一条热指令实现：

rep    stos %al,%es:(%rdi)

手动循环编译为实际的128位指令的位置：

add    $0x1,%rax                                                                                                       
add    $0x10,%rdx                                                                                                      
movaps %xmm0,-0x10(%rdx)                                                                                               
cmp    %rax,%r8                                                                                                        
ja     400f41

有趣的是，虽然有针对字节类型的std::fillvia可以实现模板/头优化memset，但是在这种情况下，它是编译器优化，可以转换实际的循环。奇怪的是std::vector<char>，gcc也开始优化fill(1)。尽管有memset模板规范，英特尔编译器也不会。

由于仅在代码实际在内存而不是在缓存中工作时才会发生这种情况，因此Haswell-EP体系结构似乎无法有效地合并单字节写操作。

如果您对此问题以及相关的微体系结构有任何进一步的了解，我将不胜感激。特别是对于我来说，目前尚不清楚为什么四个或更多线程的行为如此不同，以及为什么memset在缓存中如此之快。

更新：

这是与之比较的结果

• 使用-march=native（avx2 vmovdq %ymm0）的fill（1）-在L1中效果更好，但与movaps %xmm0其他内存级别的版本相似。
• 32、128和256位非临时存储的变体。无论数据大小如何，它们始终以相同的性能运行。所有这些都优于其他内存变体，特别是对于少量线程。128位和256位的性能完全相似，而线程数较少时32位的性能则明显较差。

对于<= 6线程，vmovnt与rep stos在内存中进行操作相比，具有2倍的优势。

单线程带宽：

内存中的总带宽：

这是用于带有附加热循环的附加测试的代码：

void __attribute__ ((noinline)) fill1(vector& v) {
    std::fill(v.begin(), v.end(), 1);
}
┌─→add    $0x1,%rax
│  vmovdq %ymm0,(%rdx)
│  add    $0x20,%rdx
│  cmp    %rdi,%rax
└──jb     e0


void __attribute__ ((noinline)) fill1_nt_si32(vector& v) {
    for (auto& elem : v) {
       _mm_stream_si32(&elem, 1);
    }
}
┌─→movnti %ecx,(%rax)
│  add    $0x4,%rax
│  cmp    %rdx,%rax
└──jne    18


void __attribute__ ((noinline)) fill1_nt_si128(vector& v) {
    assert((long)v.data() % 32 == 0); // alignment
    const __m128i buf = _mm_set1_epi32(1);
    size_t i;
    int* data;
    int* end4 = &v[v.size() - (v.size() % 4)];
    int* end = &v[v.size()];
    for (data = v.data(); data < end4; data += 4) {
        _mm_stream_si128((__m128i*)data, buf);
    }
    for (; data < end; data++) {
        *data = 1;
    }
}
┌─→vmovnt %xmm0,(%rdx)
│  add    $0x10,%rdx
│  cmp    %rcx,%rdx
└──jb     40


void __attribute__ ((noinline)) fill1_nt_si256(vector& v) {
    assert((long)v.data() % 32 == 0); // alignment
    const __m256i buf = _mm256_set1_epi32(1);
    size_t i;
    int* data;
    int* end8 = &v[v.size() - (v.size() % 8)];
    int* end = &v[v.size()];
    for (data = v.data(); data < end8; data += 8) {
        _mm256_stream_si256((__m256i*)data, buf);
    }
    for (; data < end; data++) {
        *data = 1;
    }
}
┌─→vmovnt %ymm0,(%rdx)
│  add    $0x20,%rdx
│  cmp    %rcx,%rdx
└──jb     40

注意：为了使循环如此紧凑，我必须进行手动指针计算。否则，它可能会在循环内执行矢量索引编制，这可能是由于固有的优化器混乱所致。