【问题标题】:SIMD Linear Search Slower than Unrolled LoopSIMD 线性搜索比展开循环慢
【发布时间】:2017-12-16 12:15:53
【问题描述】:

我正在开发一个应用程序,高度优化的线性搜索将对整体性能产生重大影响,我的任务是尽可能提高性能。

我在一个由 10,000 个元素组成的向量上运行我的搜索,该向量最后以标记值为界,我在距目标元素一定距离处运行线性搜索并测量找到该元素所花费的时间。我从一组元素中随机选择目标元素,这些元素位于距数组开头的恒定距离之后,以允许开始搜索。我正在使用Google's benchmark framework 衡量性能。

我收集的结果让我感到惊讶。我预计在某些时候 SIMD 会在性能方面击败展开的循环,但是随着移动阵列所需距离的增加,两者之间的差距似乎也在扩大。此外,我不确定为什么展开 8 次的循环在较短的距离上比展开 32 次的循环运行得更快。

Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
BM_Search<linUnroll<8>>/2             86 ns         86 ns    7699241
BM_Search<linUnroll<8>>/4            103 ns        103 ns    6797378
BM_Search<linUnroll<8>>/16           650 ns        650 ns    1079095
BM_Search<linUnroll<8>>/64          1365 ns       1365 ns     514196
BM_Search<linUnroll<8>>/256         3558 ns       3558 ns     196519
BM_Search<linUnroll<8>>/1024       12358 ns      12358 ns      56635
BM_Search<linUnroll<8>>/4096       47341 ns      47341 ns      14780
BM_Search<linUnroll<8>>/8192       95029 ns      95030 ns       7367
BM_Search<linUnroll<32>>/2           131 ns        131 ns    5337221
BM_Search<linUnroll<32>>/4           131 ns        131 ns    5329296
BM_Search<linUnroll<32>>/16          291 ns        291 ns    2404646
BM_Search<linUnroll<32>>/64          836 ns        836 ns     831093
BM_Search<linUnroll<32>>/256        2776 ns       2776 ns     252901
BM_Search<linUnroll<32>>/1024      10962 ns      10962 ns      63828
BM_Search<linUnroll<32>>/4096      41312 ns      41312 ns      16941
BM_Search<linUnroll<32>>/8192      83303 ns      83304 ns       8401
BM_Search<linSIMD>/2                 163 ns        163 ns    4304086
BM_Search<linSIMD>/4                 208 ns        208 ns    3354716
BM_Search<linSIMD>/16                366 ns        366 ns    1912122
BM_Search<linSIMD>/64                871 ns        871 ns     803854
BM_Search<linSIMD>/256              3333 ns       3334 ns     210159
BM_Search<linSIMD>/1024            11262 ns      11262 ns      62157
BM_Search<linSIMD>/4096            42656 ns      42656 ns      16413
BM_Search<linSIMD>/8192            87824 ns      87824 ns       7970

我在 i5-4570 上运行,并且遵守了 clang 5.0.0。 quick-bench 没有 AVX,并且 clang 在 3.8 版本中没有完全展开,但它应该是可运行的。我也尝试展开 SIMD,以及转到 AVX256 指令,但都使性能变差。为什么展开的循环要快得多?为什么展开次数多的循环比展开次数少的循环执行得差这么多?

SIMD 的经典诊断是您在 SIMD 中没有做足够的工作,但我认为我在这里做的工作已经足够了。

#include <vector>
#include <cinttypes>
#include <immintrin.h>
typedef int V;
typedef std::vector<V> vi;

long linSIMD(const vi& arr, const long guessIx, const V x) {
  using v4 = V __attribute__ ((vector_size (4*4)));
  using dv2 = int64_t __attribute__ ((vector_size (4*4)));
  constexpr int roll = 4;
  constexpr union {
    int32_t i32[2];
    int64_t i64;
  } skip = {-2,-2};
  v4 xVec = {x,x,x,x};
  for (int i = guessIx;; i += roll) {
    v4 arrVec;
    for (long j = 0; j < 4; j++) arrVec[j] = arr[i+j];
    union {
        v4 i32;
        dv2 i64;
    } cmpVec = {arrVec < xVec};
    v4 cmpVec2 = {cmpVec.i32[3], cmpVec.i32[2], cmpVec.i32[1],cmpVec.i32[0]};
    cmpVec.i32 += cmpVec2;
    if (cmpVec.i64[0] == skip.i64) continue;
    return i - cmpVec.i32[0] - cmpVec.i32[1];
  }
}

long linUnroll32(const vi& arr, const long guessIx, const V x) {
  constexpr int roll = 32;
  for (long i = guessIx;; i += roll)
    for (long j = 0; j < roll; j++)
        if (arr[i+j] >= x) return i+j;
}

http://quick-bench.com/_x_v_WXLWtwvvLsObNlIxjXxS_g https://godbolt.org/g/Wyx2pS

【问题讨论】:

  • 你必须像那样使用cryptic-SIMD吗?我可以解释发生了什么的唯一方法是通过反汇编
  • godbolt.org/g/4AaAYN 你似乎做了很多工作来以某种方式进行设置,而不是仅仅通过内存进行线性搜索,这与缓存友好度差不多。
  • @harold 我刚刚链接到它
  • @eyepatch:嗯,SSE 变体在这里看起来主要是开销。有一个单一的四元素比较指令,然后是到整数单元的转换,以及一个 shuffle/add 以获取信息以及潜在的未对齐负载。我想您已经排除了使用替代数据结构来加快搜索速度的选项?
  • 这里有一些基准测试:quick-bench.com/lkdHZ1Nxc1p7qfG7o3bHkLe-Bcc

标签: c++ performance search sse simd


【解决方案1】:

我能做的最好的事情(查看quick-bench 上的结果)就是这样,

int linSIMD4(const vi& arr, const int guessIx, const int x) {
  auto vecX = _mm_set1_epi32(x - 1);
  const int *ptr = arr.data();
  int i = guessIx;
  // unaligned start
  int misalignment = (uintptr_t)(ptr + i) & 15;
  auto arrVec = _mm_loadu_si128((__m128i*)(ptr + i));
  auto cmp = _mm_cmpgt_epi32(arrVec, vecX);
  int mask = _mm_movemask_ps(_mm_castsi128_ps(cmp));
  if (mask)
    return i + __builtin_ctz(mask);
  // continue with aligned part
  i += (16 - misalignment) / 4;
  for (; ; i += 16) {
    auto av0 = _mm_load_si128((__m128i*)(ptr + i));
    auto av1 = _mm_load_si128((__m128i*)(ptr + i + 4));
    auto av2 = _mm_load_si128((__m128i*)(ptr + i + 8));
    auto av3 = _mm_load_si128((__m128i*)(ptr + i + 12));
    auto cmp0 = _mm_cmpgt_epi32(av0, vecX);
    auto cmp1 = _mm_cmpgt_epi32(av1, vecX);
    auto cmp2 = _mm_cmpgt_epi32(av2, vecX);
    auto cmp3 = _mm_cmpgt_epi32(av3, vecX);
    auto cmp = _mm_packs_epi16(_mm_packs_epi32(cmp0, cmp1), _mm_packs_epi32(cmp2, cmp3));
    int mask = _mm_movemask_epi8(cmp);
    if (mask)
      return i + __builtin_ctz(mask);
  }
}

这基本上是 geza 所描述的,但我添加了一个特殊的第一次迭代,以便对齐主循环的数据。跨越缓存线边界(或页面边界)的加载速度较慢,这可以摆脱它们。对于小距离(没有足够慢的负载),开销不值得,另一方面,对于小距离(小于 4),它应该再次更快。

我还尝试使用 (a &gt;= b) = !(b &gt; a) 翻转条件 (linSIMD5),使用非破坏性 AVX 编码允许合并 vcmpgtd 和负载(减少融合域中的微操作),但速度很快-bench 不做 AVX,所以忽略结果并自己尝试。

底部有一个 AVX2 版本,我没有尝试过或对其进行基准测试。它不使用加载/比较合并技巧(这可能有帮助,也可能没有帮助),但很容易适应。

【讨论】:

  • 我运行了 linSIMD5,发现它稍微差一点。 ptest 也让事情变得更糟。它可以帮助用展开的循环替换未对齐的 SIMD 批处理。您在 4-16 范围内损失了几纳秒,但在 0-4 范围内获得更多。您的 AVX 代码中存在错误。 256 位包执行 A 通道、B 通道、A 通道、B 通道。可以通过用这个向量置换来修复它:(7,3,6,2,5,1,4,0​​)(像构造函数一样倒序)
  • @eyepatch AVX 代码已经从车道中撤消了奇怪的隐式洗牌,当然它可能是错误的(如果reorder 是错误的)但我认为不需要任何置换(它也可以通过随机播放来完成,但这是一个烦人的随机播放)
  • 我在一些测试用例上运行它,它返回了错误的结果。它进入 0xfffffeff00 或类似的状态,其中正确的结果类似于 i+12,但返回的结果是 i+8。由于通道交错的方式,似乎不可能像您那样对阵列进行处理,尽管如果可以,那可能会更快。由于 0xffffffff00 和 0xfffffeff00 返回相同的 ctz,这似乎是微不足道的。交织的符号是 0..f,然后是 00..ff。 0,1,2,3,8,9,a,b,00,11,22,33,88,99,aa,bb,4,5,6,7,c,d,e,f,44, 55,66,77,cc,dd,ee,ff
  • @eyepatch 好的,是的,我想它不一定会找到 first 项目,这很烦人.. 那就别管那个想法了
【解决方案2】:

在 SIMD 情况下,在循环中使用更大的批次。

例如,对 4 个 SIMD 寄存器使用比较,然后将得到的 16 个比较结果放入一个 SIMD 寄存器。然后在上面放置一个分支(如果找到匹配项,则从循环中中断)。这样,您将拥有:

  1. 更少的分支
  2. 为编译器和 CPU 提供更多可能的并行化机会

从循环中中断后,您需要在 16 个可能的条目中找到匹配的索引。您可以使用 SIMD 或任何您喜欢的方法来完成。

这种方式应该比您当前的实现更快(对于大型数组)。

【讨论】:

  • 我讨论过我两次展开 SIMD,但我会去建立一个基准和测量。
  • 您还需要更改分支,这很重要(因此解决方案不仅仅是复制粘贴循环两次)。我建议至少使用 4 个输入寄存器,这样可以循环处理 16 个数字。
  • @eyepatch:查看 harold 的 linSIMD3,基本上它是我建议的实现。这个 quick-bench.com 很棒 :)
猜你喜欢
  • 2021-09-17
  • 1970-01-01
  • 2016-05-16
  • 2020-09-17
  • 2011-07-31
  • 2015-09-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多