用于小型未对齐数据的快速 memcpy

Ins*_*oop 5 c++ memory performance

我需要读取一个由许多基本类型组成的二进制文件,例如 int、double、UTF8 字符串等。例如,考虑一个文件包含 n 对 (int, double) 一个接一个,没有任何对齐n 在数千万的数量级。我需要非常快速地访问该文件。我使用fread调用和我自己的大约 16 kB 长的缓冲区读取文件。

分析器显示我的主要瓶颈恰好是从内存缓冲区复制到其最终目的地。编写从缓冲区复制到双精度的函数的最明显方法是:

// x: a pointer to the final destination of the data
// p: a pointer to the buffer used to read the file
//
void f0(double* x, const unsigned char* p) {
  unsigned char* q = reinterpret_cast<unsigned char*>(x);
  for (int i = 0; i < 8; ++i) {
    q[i] = p[i];
  }
}
Run Code Online (Sandbox Code Playgroud)

我使用以下代码,我在 x86-64 上获得了巨大的加速

void f1(double* x, const unsigned char* p) {
  double* r = reinterpret_cast<const double*>(p);
  *x = *r;
}
Run Code Online (Sandbox Code Playgroud)

但是,据我所知,如果 p 不是 8 字节对齐的,程序会在 ARM 上崩溃。

以下是我的问题:

  • 第二个程序是否保证可以在 x86 和 x86-64 上运行?
  • 如果您需要尽快在 ARM 上编写这样的函数,您会怎么做?

这是在你的机器上测试的一个小基准

#include <chrono>
#include <iostream>

void copy_int_0(int* x, const unsigned char* p) {
  unsigned char* q = reinterpret_cast<unsigned char*>(x);
  for (std::size_t i = 0; i < 4; ++i) {
    q[i] = p[i];
  }
}

void copy_double_0(double* x, const unsigned char* p) {
  unsigned char* q = reinterpret_cast<unsigned char*>(x);
  for (std::size_t i = 0; i < 8; ++i) {
    q[i] = p[i];
  }
}

void copy_int_1(int* x, const unsigned char* p) {
  *x = *reinterpret_cast<const int*>(p);
}

void copy_double_1(double* x, const unsigned char* p) {
  *x = *reinterpret_cast<const double*>(p);
}

int main() {
  const std::size_t n = 10000000;
  const std::size_t nb_times = 200;
  unsigned char* p = new unsigned char[12 * n];
  for (std::size_t i = 0; i < 12 * n; ++i) {
    p[i] = 0;
  }
  int* q0 = new int[n];
  for (std::size_t i = 0; i < n; ++i) {
    q0[i] = 0;
  }
  double* q1 = new double[n];
  for (std::size_t i = 0; i < n; ++i) {
    q1[i] = 0.0;
  }

  const auto begin_0 = std::chrono::high_resolution_clock::now();
  for (std::size_t k = 0; k < nb_times; ++k) {
    for (std::size_t i = 0; i < n; ++i) {
      copy_int_0(q0 + i, p + 12 * i);
      copy_double_0(q1 + i, p + 4 + 12 * i);
    }
  }
  const auto end_0 = std::chrono::high_resolution_clock::now();
  const double time_0 =
      1.0e-9 *
      std::chrono::duration_cast<std::chrono::nanoseconds>(end_0 - begin_0)
          .count();
  std::cout << "Time 0: " << time_0 << " s" << std::endl;

  const auto begin_1 = std::chrono::high_resolution_clock::now();
  for (std::size_t k = 0; k < nb_times; ++k) {
    for (std::size_t i = 0; i < n; ++i) {
      copy_int_1(q0 + i, p + 12 * i);
      copy_double_1(q1 + i, p + 4 + 12 * i);
    }
  }
  const auto end_1 = std::chrono::high_resolution_clock::now();
  const double time_1 =
      1.0e-9 *
      std::chrono::duration_cast<std::chrono::nanoseconds>(end_1 - begin_1)
          .count();
  std::cout << "Time 1: " << time_1 << " s" << std::endl;
  std::cout << "Prevent optimization: " << q0[0] << " " << q1[0] << std::endl;

  delete[] q1;
  delete[] q0;
  delete[] p;

  return 0;
}
Run Code Online (Sandbox Code Playgroud)

我得到的结果是

clang++ -std=c++11 -O3 -march=native copy.cpp -o copy
./copy
Time 0: 8.49403 s
Time 1: 4.01617 s

g++ -std=c++11 -O3 -march=native copy.cpp -o copy
./copy
Time 0: 8.65762 s
Time 1: 3.89979 s

icpc -std=c++11 -O3 -xHost copy.cpp -o copy
./copy
Time 0: 8.46155 s
Time 1: 0.0278496 s
Run Code Online (Sandbox Code Playgroud)

我还没有检查程序集,但我猜英特尔编译器在这里欺骗了我的基准测试。

nem*_*equ 5

第二个程序是否保证可以在 x86 和 x86-64 上运行?

不。

当您取消引用 a 时double*,编译器可以自由地假定内存位置实际上包含一个双精度值,这意​​味着它必须与alignof(double).

许多 x86 指令可安全用于未对齐的数据,但并非全部。具体来说,有一些 SIMD 指令需要正确对齐,您的编译器可以自由使用。

这不仅仅是理论上的;LZ4 曾经使用与您发布的内容非常相似的东西(它是 C,而不是 C++,所以它是 C 风格的强制转换 not reinterpret_cast,但这并不重要),并且一切都按预期工作。然后 GCC 5 发布,它使用 自动矢量化-O3 处的相关代码vmovdqa,这需要正确对齐。最终结果是在 GCC 中运行良好的代码?4.9 使用 GCC 编译时在运行时开始崩溃?5.

换句话说,即使您的程序今天碰巧可以运行,如果您依赖于未对齐的访问(或其他未定义的行为),它明天也很容易停止运行。不要这样做。

如果您需要尽快在 ARM 上编写这样的函数,您会怎么做?

答案并不是特定于 ARM 的。LZ4事件后Yann Collet(LZ4的作者)做了很多研究来回答这个问题。没有一种选择可以很好地为每种架构上的每个编译器生成最佳代码。

使用memcpy()是最安全的选择。如果在编译时已知大小,编译器通常会优化memcpy()调用……对于更大的缓冲区,您可以通过memcpy()在循环中调用来利用它;您通常会得到一个快速指令循环,而不会产生调用memcpy().

如果您更喜欢冒险,您可以使用压缩联合来“强制转换”而不是reinterpret_cast. 这是特定于编译器的,但如果支持它应该是安全的,并且可能memcpy().

FWIW,我有一些代码试图根据各种因素(编译器、编译器版本、体系结构等)找到执行此操作的最佳方法。我没有测试过的平台有点保守,但它应该在人们实际使用的绝大多数平台上取得良好的效果。