理解std::transform以及如何战胜它

Understanding std::transform and how to beat it

本文关键字:何战胜 std transform 理解      更新时间:2023-10-16

我试图理解一个简单、具体问题的面向数据的设计。如果我做了一些非常愚蠢的事情,请提前向面向数据的设计人员道歉,但我很难理解为什么以及在哪里我的推理失败了。

假设我有一个简单的操作,,即float_t result = int_t(lhs) / int_t(rhs)。如果我将所有变量都保存在它们对应的容器中,,例如std::vector<float_t>std::vector<int_t>,并使用std::transform,我会得到正确的结果。然后,对于using float_t = floatusing int_t = int16_t的一个特定示例,我假设在64位体系结构上,将这些变量封装在struct中,并将它们收集在容器中,应该会产生更好的性能。

我认为struct构成了一个64位对象,对struct的一次内存访问将为我提供所需的所有变量。另一方面,当所有这些变量都收集在不同的容器中时,我将需要三种不同的内存访问来获得所需的信息。以下是我如何设置环境:

#include <algorithm>
#include <chrono>
#include <cstdint>
#include <iostream>
#include <vector>
using namespace std::chrono;
template <class float_t, class int_t> struct Packed {
float_t sinvl;
int_t s, l;
Packed() = default;
Packed(float_t sinvl, int_t s, int_t l) : sinvl{sinvl}, s{s}, l{l} {}
void comp() { sinvl = float_t(l) / s; }
};
using my_float = float;
using my_int = int16_t;
int main(int argc, char *argv[]) {
constexpr uint32_t M{100};
for (auto N : {1000, 10000, 100000}) {
double t1{0}, t2{0};
for (uint32_t m = 0; m < M; m++) {
std::vector<my_float> sinvl(N, 0.0);
std::vector<my_int> s(N, 3), l(N, 2);
std::vector<Packed<my_float, my_int>> p1(
N, Packed<my_float, my_int>(0.0, 3, 2));
// benchmark unpacked
auto tstart = high_resolution_clock::now();
std::transform(l.cbegin(), l.cend(), s.cbegin(), sinvl.begin(),
std::divides<my_float>{}); // 3 different memory accesses
auto tend = high_resolution_clock::now();
t1 += duration_cast<microseconds>(tend - tstart).count();
if (m == M - 1)
std::cout << "sinvl[0]: " << sinvl[0] << 'n';
// benchmark packed
tstart = high_resolution_clock::now();
for (auto &elem : p1) // 1 memory access
elem.comp();
tend = high_resolution_clock::now();
t2 += duration_cast<microseconds>(tend - tstart).count();
if (m == M - 1)
std::cout << "p1[0].sinvl: " << p1[0].sinvl << 'n';
}
std::cout << "N = " << N << ", unpacked: " << (t1 / M) << " us.n";
std::cout << "N = " << N << ", packed: " << (t2 / M) << " us.n";
}
return 0;
}

使用g++ -O3编译的代码在我的机器上产生

sinvl[0]: 0.666667
p1[0].sinvl: 0.666667
N = 1000, unpacked: 0 us.
N = 1000, packed: 1 us.
sinvl[0]: 0.666667
p1[0].sinvl: 0.666667
N = 10000, unpacked: 5.06 us.
N = 10000, packed: 12.97 us.
sinvl[0]: 0.666667
p1[0].sinvl: 0.666667
N = 100000, unpacked: 52.31 us.
N = 100000, packed: 124.49 us.

基本上,std::transform击败了2.5x的打包访问。如果你能帮助我理解这种行为,我将不胜感激。结果是造成的吗

  1. 我没有正确掌握面向数据的设计原则,或者
  2. 这个非常简单的例子的一些假象,比如内存位置被分配得非常接近,并且在某种程度上被编译器非常有效地优化

最后,在这个例子中,有没有一种方法可以击败std::transform,或者,它是否足以成为一个现成的解决方案?我既不是编译器优化专家,也不是面向数据设计专家,因此,我自己无法回答这个问题。

谢谢!

编辑根据@bolov在评论中的建议,我已经改变了测试这两种方法的方式。

现在代码看起来像:

#include <algorithm>
#include <chrono>
#include <cstdint>
#include <iostream>
#include <vector>
using namespace std::chrono;
template <class float_t, class int_t> struct Packed {
float_t sinvl;
int_t s, l;
Packed() = default;
Packed(float_t sinvl, int_t s, int_t l) : sinvl{sinvl}, s{s}, l{l} {}
void comp() { sinvl = float_t(l) / s; }
};
using my_float = float;
using my_int = int16_t;
int main(int argc, char *argv[]) {
uint32_t N{1000};
double t{0};
if (argc == 2)
N = std::stoul(argv[1]);
#ifndef _M_PACKED
std::vector<my_float> sinvl(N, 0.0);
std::vector<my_int> s(N, 3), l(N, 2);
// benchmark unpacked
auto tstart = high_resolution_clock::now();
std::transform(l.cbegin(), l.cend(), s.cbegin(), sinvl.begin(),
std::divides<my_float>{}); // 3 different memory accesses
auto tend = high_resolution_clock::now();
t += duration_cast<microseconds>(tend - tstart).count();
std::cout << "sinvl[0]: " << sinvl[0] << 'n';
std::cout << "N = " << N << ", unpacked: " << t << " us.n";
#else
std::vector<Packed<my_float, my_int>> p1(N,
Packed<my_float, my_int>(0.0, 3, 2));
// benchmark packed
auto tstart = high_resolution_clock::now();
for (auto &elem : p1) // 1 memory access
elem.comp();
auto tend = high_resolution_clock::now();
t += duration_cast<microseconds>(tend - tstart).count();
std::cout << "p1[0].sinvl: " << p1[0].sinvl << 'n';
std::cout << "N = " << N << ", packed: " << t << " us.n";
#endif
return 0;
}

带有相应的shell(fish)脚本

g++ -Wall -std=c++11 -O3 transform.cpp -o transform_unpacked.out
g++ -Wall -std=c++11 -O3 transform.cpp -o transform_packed.out -D_M_PACKED
for N in 1000 10000 100000
echo "Testing unpacked for N = $N"
./transform_unpacked.out $N
./transform_unpacked.out $N
./transform_unpacked.out $N
echo "Testing packed for N = $N"
./transform_packed.out $N
./transform_packed.out $N
./transform_packed.out $N
end

它给出以下内容:

Testing unpacked for N = 1000
sinvl[0]: 0.666667
N = 1000, unpacked: 0 us.
sinvl[0]: 0.666667
N = 1000, unpacked: 0 us.
sinvl[0]: 0.666667
N = 1000, unpacked: 0 us.
Testing packed for N = 1000
p1[0].sinvl: 0.666667
N = 1000, packed: 1 us.
p1[0].sinvl: 0.666667
N = 1000, packed: 1 us.
p1[0].sinvl: 0.666667
N = 1000, packed: 1 us.
Testing unpacked for N = 10000
sinvl[0]: 0.666667
N = 10000, unpacked: 5 us.
sinvl[0]: 0.666667
N = 10000, unpacked: 5 us.
sinvl[0]: 0.666667
N = 10000, unpacked: 5 us.
Testing packed for N = 10000
p1[0].sinvl: 0.666667
N = 10000, packed: 17 us.
p1[0].sinvl: 0.666667
N = 10000, packed: 13 us.
p1[0].sinvl: 0.666667
N = 10000, packed: 13 us.
Testing unpacked for N = 100000
sinvl[0]: 0.666667
N = 100000, unpacked: 64 us.
sinvl[0]: 0.666667
N = 100000, unpacked: 66 us.
sinvl[0]: 0.666667
N = 100000, unpacked: 66 us.
Testing packed for N = 100000
p1[0].sinvl: 0.666667
N = 100000, packed: 180 us.
p1[0].sinvl: 0.666667
N = 100000, packed: 198 us.
p1[0].sinvl: 0.666667
N = 100000, packed: 177 us.

我希望我已经正确地理解了正确的测试方法。不过,两者的差距还是2-3倍。

以下是std::transform案例的编译循环:

400fd0:       f3 41 0f 7e 04 47       movq   xmm0,QWORD PTR [r15+rax*2]
400fd6:       66 0f 61 c0             punpcklwd xmm0,xmm0
400fda:       66 0f 72 e0 10          psrad  xmm0,0x10
400fdf:       0f 5b c0                cvtdq2ps xmm0,xmm0
400fe2:       f3 0f 7e 0c 43          movq   xmm1,QWORD PTR [rbx+rax*2]
400fe7:       66 0f 61 c9             punpcklwd xmm1,xmm1
400feb:       66 0f 72 e1 10          psrad  xmm1,0x10
400ff0:       0f 5b c9                cvtdq2ps xmm1,xmm1
400ff3:       0f 5e c1                divps  xmm0,xmm1
400ff6:       41 0f 11 04 80          movups XMMWORD PTR [r8+rax*4],xmm0
400ffb:       f3 41 0f 7e 44 47 08    movq   xmm0,QWORD PTR [r15+rax*2+0x8]
401002:       66 0f 61 c0             punpcklwd xmm0,xmm0
401006:       66 0f 72 e0 10          psrad  xmm0,0x10
40100b:       0f 5b c0                cvtdq2ps xmm0,xmm0
40100e:       f3 0f 7e 4c 43 08       movq   xmm1,QWORD PTR [rbx+rax*2+0x8]
401014:       66 0f 61 c9             punpcklwd xmm1,xmm1
401018:       66 0f 72 e1 10          psrad  xmm1,0x10
40101d:       0f 5b c9                cvtdq2ps xmm1,xmm1
401020:       0f 5e c1                divps  xmm0,xmm1
401023:       41 0f 11 44 80 10       movups XMMWORD PTR [r8+rax*4+0x10],xmm0
401029:       48 83 c0 08             add    rax,0x8
40102d:       48 83 c1 02             add    rcx,0x2
401031:       75 9d                   jne    400fd0 <main+0x570>

在每个循环周期中,它处理8个元素(有两个divps指令,每个指令执行4个除法)。

这是另一种情况:

401190:       f3 0f 6f 42 04          movdqu xmm0,XMMWORD PTR [rdx+0x4]
401195:       f3 0f 6f 4a 14          movdqu xmm1,XMMWORD PTR [rdx+0x14]
40119a:       66 0f 70 c9 e8          pshufd xmm1,xmm1,0xe8
40119f:       66 0f 70 c0 e8          pshufd xmm0,xmm0,0xe8
4011a4:       f2 0f 70 d0 e8          pshuflw xmm2,xmm0,0xe8
4011a9:       66 0f 6c c1             punpcklqdq xmm0,xmm1
4011ad:       66 0f 72 e0 10          psrad  xmm0,0x10
4011b2:       0f 5b c0                cvtdq2ps xmm0,xmm0
4011b5:       f2 0f 70 c9 e8          pshuflw xmm1,xmm1,0xe8
4011ba:       66 0f 62 d1             punpckldq xmm2,xmm1
4011be:       66 0f 61 ca             punpcklwd xmm1,xmm2
4011c2:       66 0f 72 e1 10          psrad  xmm1,0x10
4011c7:       0f 5b c9                cvtdq2ps xmm1,xmm1
4011ca:       0f 5e c1                divps  xmm0,xmm1
4011cd:       f3 0f 11 02             movss  DWORD PTR [rdx],xmm0
4011d1:       0f 28 c8                movaps xmm1,xmm0
4011d4:       0f c6 c9 e5             shufps xmm1,xmm1,0xe5
4011d8:       f3 0f 11 4a 08          movss  DWORD PTR [rdx+0x8],xmm1
4011dd:       0f 28 c8                movaps xmm1,xmm0
4011e0:       0f 12 c9                movhlps xmm1,xmm1
4011e3:       f3 0f 11 4a 10          movss  DWORD PTR [rdx+0x10],xmm1
4011e8:       0f c6 c0 e7             shufps xmm0,xmm0,0xe7
4011ec:       f3 0f 11 42 18          movss  DWORD PTR [rdx+0x18],xmm0
4011f1:       48 83 c2 20             add    rdx,0x20
4011f5:       48 83 c1 fc             add    rcx,0xfffffffffffffffc
4011f9:       75 95                   jne    401190 <main+0x730>

在每个循环周期中,它处理4个元素(有一条divps指令)。

在第一种情况下,数据的格式很好,SIMD指令可以(几乎)在没有任何数据移动的情况下对其进行操作,并且可以很容易地写入结果(用一条指令写入4个结果)。

然而,在第二种情况下,情况并非如此。编译器必须发出大量的数据移动(shuffle)操作,每个结果都用一条单独的指令编写。因此,输入/输出不是SIMD友好格式。

我没有时间进一步分析这个问题,但如果你只考虑这两个片段大小相似,指令相似,但第一个片段处理的元素是第二个片段的两倍,你就会知道为什么第二个更慢。抱歉解释得太草率了。

[…]并将它们收集在容器中应该会产生更好的效果表演

对于顺序访问情况,我认为您的直觉有点落后。仅考虑在非平凡大小的输入上的顺序循环,对于顺序访问,SoA几乎总是与AoS一样快或更快。

在许多情况下,SoA实际上会比AoS减少缓存未命中总数,因为它避免了结构填充(不面临交错非齐次场的对齐要求),并且您可能能够避免为给定循环加载冷场(例如:物理模拟器可能能够避免在应用物理时加载仅用于渲染的粒子的color场)。你的案子没有从这两件事中受益,但需要记住。

AoS的优势在于随机访问。在这种情况下,如果加载4096个元素,可能只需要一个带有AoS的缓存行就可以获取所有三个字段。如果使用SoA,则需要3,并且它可能会加载大量相邻元素的数据(元素4097、4098、4099等的数据),由于内存访问模式的随机访问特性,这些数据在驱逐之前都不会被使用。但对于顺序访问,即使在驱逐之前使用SoA rep,也通常会使用所有此类相邻数据。

因此,在按顺序循环非琐碎输入大小的情况下,就缓存未命中而言,SoA通常会打平或获胜。

但是,在这种顺序访问模式中,在驱逐之前将使用所有相邻数据,当您考虑数据从缓存加载到SIMD寄存器时的动态时,SoA提供了同质数据。它可以以float, float, float, float, ...int16, int16, int16, int16, ...的形式加载存储器,而不是在SIMD寄存器之间执行垂直/对称操作的float, int16, int16, float, int16, int16 ...。这种情况往往为人类和编译器提供更多的优化机会,正如Geza所指出的,这可能是您的特定情况受益最大的地方。

最后,在这个例子中,有没有一种方法可以击败std::transform,或者,是它仅仅是一个好的解决方案吗?

我认为,试图在满足相同要求的同时击败std::transform是错误的看待方式,但您可以通过稍微改变它们来获得一些性能提升。例如,您可以提前准备数据,将其转换为乘法,而不是std::divides。在您的情况下,我想寻找的最大的事情是看看代码是否可以与更快的SoA("unpacked")rep并行执行。您可能能够在每个单独的线程中处理每个SoA容器的给定索引范围,仍然在每个线程中使用std::transform