用 64 位替换 32 位循环计数器会在 Intel CPU 上使用 _mm_popcnt_u64 引入疯狂的性能偏差 [英] Replacing a 32-bit loop counter with 64-bit introduces crazy performance deviations with _mm_popcnt_u64 on Intel CPUs
问题描述
我一直在寻找popcount 大型数据数组的最快方法.我遇到了一个非常奇怪的效果:将循环变量从 unsigned 更改为 uint64_t 使我的 PC 上的性能下降了 50%.
I was looking for the fastest way to popcount large arrays of data. I encountered a very weird effect: Changing the loop variable from unsigned to uint64_t made the performance drop by 50% on my PC.
#include <iostream>
#include <chrono>
#include <x86intrin.h>
int main(int argc, char* argv[]) {
using namespace std;
if (argc != 2) {
cerr << "usage: array_size in MB" << endl;
return -1;
}
uint64_t size = atol(argv[1])<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer = reinterpret_cast<char*>(buffer);
for (unsigned i=0; i<size; ++i)
charbuffer[i] = rand()%256;
uint64_t count,duration;
chrono::time_point<chrono::system_clock> startP,endP;
{
startP = chrono::system_clock::now();
count = 0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with unsigned
for (unsigned i=0; i<size/8; i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "unsigned " << count << ' ' << (duration/1.0E9) << " sec "
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
{
startP = chrono::system_clock::now();
count=0;
for( unsigned k = 0; k < 10000; k++){
// Tight unrolled loop with uint64_t
for (uint64_t i=0;i<size/8;i+=4) {
count += _mm_popcnt_u64(buffer[i]);
count += _mm_popcnt_u64(buffer[i+1]);
count += _mm_popcnt_u64(buffer[i+2]);
count += _mm_popcnt_u64(buffer[i+3]);
}
}
endP = chrono::system_clock::now();
duration = chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "uint64_t " << count << ' ' << (duration/1.0E9) << " sec "
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}
如您所见，我们创建了一个随机数据缓冲区，大小为 x 兆字节，其中 x 是从命令行读取的.之后，我们遍历缓冲区并使用 x86 popcount 内在函数的展开版本来执行 popcount.为了获得更精确的结果，我们进行了 10,000 次 popcount.我们测量popcount的时间.大写时，内循环变量为unsigned，小写时，内循环变量为uint64_t.我认为这应该没什么区别，但情况恰恰相反.
As you see, we create a buffer of random data, with the size being x megabytes where x is read from the command line. Afterwards, we iterate over the buffer and use an unrolled version of the x86 popcount intrinsic to perform the popcount. To get a more precise result, we do the popcount 10,000 times. We measure the times for the popcount. In the upper case, the inner loop variable is unsigned, in the lower case, the inner loop variable is uint64_t. I thought that this should make no difference, but the opposite is the case.
我是这样编译的(g++版本:Ubuntu 4.8.2-19ubuntu1):
I compile it like this (g++ version: Ubuntu 4.8.2-19ubuntu1):
g++ -O3 -march=native -std=c++11 test.cpp -o test
以下是我的 Haswell Core i7-4770K CPU @ 3.50 GHz，运行 test 1 (所以 1MB 随机数据):
Here are the results on my Haswell Core i7-4770K CPU @ 3.50 GHz, running test 1 (so 1 MB random data):
- 未签名 41959360000 0.401554 秒 26.113GB/s
- uint64_t 41959360000 0.759822 秒 13.8003GB/s
如您所见，uint64_t 版本的吞吐量只有 unsigned 版本的一半！问题似乎是生成了不同的程序集，但为什么呢?首先，我想到了一个编译器错误，所以我尝试了 clang++ (Ubuntu Clanga> 版本 3.4-1ubuntu3):
As you see, the throughput of the uint64_t version is only half the one of the unsigned version! The problem seems to be that different assembly gets generated, but why? First, I thought of a compiler bug, so I tried clang++ (Ubuntu Clang version 3.4-1ubuntu3):
clang++ -O3 -march=native -std=c++11 teest.cpp -o test
结果:test 1
- 未签名 41959360000 0.398293 秒 26.3267 GB/秒
- uint64_t 41959360000 0.680954 秒 15.3986 GB/秒
所以，结果几乎一样，还是很奇怪.但现在它变得非常奇怪.我用常量1替换了从输入读取的缓冲区大小，所以我改变了:
So, it is almost the same result and is still strange. But now it gets super strange. I replace the buffer size that was read from input with a constant 1, so I change:
uint64_t size = atol(argv[1]) << 20;
到
uint64_t size = 1 << 20;
因此，编译器现在知道编译时的缓冲区大小.也许它可以添加一些优化！以下是 g++ 的数字:
Thus, the compiler now knows the buffer size at compile time. Maybe it can add some optimizations! Here are the numbers for g++:
- 未签名 41959360000 0.509156 秒 20.5944GB/s
- uint64_t 41959360000 0.508673 秒 20.6139GB/s
现在，两个版本的速度都一样快.然而，unsigned 变得更慢！它从 26 下降到 20 GB/s，因此用常量值替换非常量会导致去优化.说真的，我不知道这里发生了什么！但是现在到 clang++ 新版本:
Now, both versions are equally fast. However, the unsigned got even slower! It dropped from 26 to 20 GB/s, thus replacing a non-constant by a constant value lead to a deoptimization. Seriously, I have no clue what is going on here! But now to clang++ with the new version:
- 未签名 41959360000 0.677009 秒 15.4884GB/s
- uint64_t 41959360000 0.676909 秒 15.4906GB/s
等等，什么?现在，两个版本都下降到了 15GB/s 的缓慢数字.因此，在 Clang 的两种情况下，用常数值替换非常量甚至会导致代码变慢！
Wait, what? Now, both versions dropped to the slow number of 15 GB/s. Thus, replacing a non-constant by a constant value even lead to slow code in both cases for Clang!
我请一位使用 Ivy Bridge CPU 的同事来编译我的基准测试.他得到了类似的结果，所以似乎不是哈斯韦尔.因为两个编译器在这里产生了奇怪的结果，所以它似乎也不是编译器错误.我们这里没有 AMD CPU，所以只能用 Intel 进行测试.
I asked a colleague with an Ivy Bridge CPU to compile my benchmark. He got similar results, so it does not seem to be Haswell. Because two compilers produce strange results here, it also does not seem to be a compiler bug. We do not have an AMD CPU here, so we could only test with Intel.
以第一个示例(带有 atol(argv[1]) 的示例)并在变量前放置一个 static，即:
Take the first example (the one with atol(argv[1])) and put a static before the variable, i.e.:
static uint64_t size=atol(argv[1])<<20;
这是我在 g++ 中的结果:
Here are my results in g++:
- 未签名 41959360000 0.396728 秒 26.4306 GB/秒
- uint64_t 41959360000 0.509484 秒 20.5811 GB/秒
是的，另一种选择.我们仍然拥有 u32 的快速 26GB/s，但我们设法使 u64 至少从 13GB/s 到 20GB/s 版本！在我同事的 PC 上，u64 版本比 u32 版本更快，产生最快的结果. 遗憾的是，这仅适用于g++、clang++ 似乎并不关心static.
Yay, yet another alternative. We still have the fast 26 GB/s with u32, but we managed to get u64 at least from the 13 GB/s to the 20 GB/s version! On my collegue's PC, the u64 version became even faster than the u32 version, yielding the fastest result of all. Sadly, this only works for g++, clang++ does not seem to care about static.
你能解释一下这些结果吗?特别是:
Can you explain these results? Especially:
u32和u64怎么会有这么大的差别?- 如何用恒定缓冲区大小替换非常量会触发优化代码?
static关键字的插入如何使u64循环更快?甚至比我同事电脑上的原始代码还要快！
- How can there be such a difference between
u32andu64? - How can replacing a non-constant by a constant buffer size trigger less optimal code?
- How can the insertion of the
statickeyword make theu64loop faster? Even faster than the original code on my collegue's computer!
我知道优化是一个棘手的领域，但是，我从未想过如此小的变化会导致执行时间100% 的差异，并且诸如恒定缓冲区大小之类的小因素可以再次混合结果完全.当然，我一直希望有能够达到 26 GB/s 的版本.我能想到的唯一可靠方法是复制粘贴这种情况下的程序集并使用内联程序集.这是我摆脱那些似乎因小改动而发狂的编译器的唯一方法.你怎么认为?有没有另一种方法可以可靠地获得最高性能的代码?
I know that optimization is a tricky territory, however, I never thought that such small changes can lead to a 100% difference in execution time and that small factors like a constant buffer size can again mix results totally. Of course, I always want to have the version that is able to popcount 26 GB/s. The only reliable way I can think of is copy paste the assembly for this case and use inline assembly. This is the only way I can get rid of compilers that seem to go mad on small changes. What do you think? Is there another way to reliably get the code with most performance?
这是各种结果的反汇编:
Here is the disassembly for the various results:
来自 g++/u32/non-const bufsize 的 26GB/s 版本:
26 GB/s version from g++ / u32 / non-const bufsize:
0x400af8:
lea 0x1(%rdx),%eax
popcnt (%rbx,%rax,8),%r9
lea 0x2(%rdx),%edi
popcnt (%rbx,%rcx,8),%rax
lea 0x3(%rdx),%esi
add %r9,%rax
popcnt (%rbx,%rdi,8),%rcx
add $0x4,%edx
add %rcx,%rax
popcnt (%rbx,%rsi,8),%rcx
add %rcx,%rax
mov %edx,%ecx
add %rax,%r14
cmp %rbp,%rcx
jb 0x400af8
来自 g++/u64/non-const bufsize 的 13 GB/s 版本:
13 GB/s version from g++ / u64 / non-const bufsize:
0x400c00:
popcnt 0x8(%rbx,%rdx,8),%rcx
popcnt (%rbx,%rdx,8),%rax
add %rcx,%rax
popcnt 0x10(%rbx,%rdx,8),%rcx
add %rcx,%rax
popcnt 0x18(%rbx,%rdx,8),%rcx
add $0x4,%rdx
add %rcx,%rax
add %rax,%r12
cmp %rbp,%rdx
jb 0x400c00
来自 clang++/u64/non-const bufsize 的 15GB/s 版本:
15 GB/s version from clang++ / u64 / non-const bufsize:
0x400e50:
popcnt (%r15,%rcx,8),%rdx
add %rbx,%rdx
popcnt 0x8(%r15,%rcx,8),%rsi
add %rdx,%rsi
popcnt 0x10(%r15,%rcx,8),%rdx
add %rsi,%rdx
popcnt 0x18(%r15,%rcx,8),%rbx
add %rdx,%rbx
add $0x4,%rcx
cmp %rbp,%rcx
jb 0x400e50
来自 g++/u32&u64/const bufsize 的 20 GB/s 版本:
20 GB/s version from g++ / u32&u64 / const bufsize:
0x400a68:
popcnt (%rbx,%rdx,1),%rax
popcnt 0x8(%rbx,%rdx,1),%rcx
add %rax,%rcx
popcnt 0x10(%rbx,%rdx,1),%rax
add %rax,%rcx
popcnt 0x18(%rbx,%rdx,1),%rsi
add $0x20,%rdx
add %rsi,%rcx
add %rcx,%rbp
cmp $0x100000,%rdx
jne 0x400a68
来自 clang++/u32&u64/const bufsize 的 15 GB/s 版本:
15 GB/s version from clang++ / u32&u64 / const bufsize:
0x400dd0:
popcnt (%r14,%rcx,8),%rdx
add %rbx,%rdx
popcnt 0x8(%r14,%rcx,8),%rsi
add %rdx,%rsi
popcnt 0x10(%r14,%rcx,8),%rdx
add %rsi,%rdx
popcnt 0x18(%r14,%rcx,8),%rbx
add %rdx,%rbx
add $0x4,%rcx
cmp $0x20000,%rcx
jb 0x400dd0
有趣的是，最快(26GB/s)的版本也是最长的！它似乎是唯一使用 lea 的解决方案.有的版本使用jb跳转，有的使用jne.但除此之外，所有版本似乎都具有可比性.我看不出 100% 的性能差距可能来自哪里，但我不太擅长破译程序集.最慢的(13GB/s)版本看起来甚至非常短而且很好.谁能解释一下?
Interestingly, the fastest (26 GB/s) version is also the longest! It seems to be the only solution that uses lea. Some versions use jb to jump, others use jne. But apart from that, all versions seem to be comparable. I don't see where a 100% performance gap could originate from, but I am not too adept at deciphering assembly. The slowest (13 GB/s) version looks even very short and good. Can anyone explain this?
不管这个问题的答案是什么；我了解到在真正的热循环中每个细节都很重要，甚至那些似乎与热代码没有任何关联的细节.我从未想过要为循环变量使用什么类型，但正如您所看到的，如此微小的更改可以产生 100% 的不同！甚至缓冲区的存储类型也会产生巨大的差异，正如我们在大小变量前面插入 static 关键字所看到的！将来，在编写对系统性能至关重要的非常紧凑和热的循环时，我将始终在各种编译器上测试各种替代方案.
No matter what the answer to this question will be; I have learned that in really hot loops every detail can matter, even details that do not seem to have any association to the hot code. I have never thought about what type to use for a loop variable, but as you see such a minor change can make a 100% difference! Even the storage type of a buffer can make a huge difference, as we saw with the insertion of the static keyword in front of the size variable! In the future, I will always test various alternatives on various compilers when writing really tight and hot loops that are crucial for system performance.
有趣的是，虽然我已经展开了四次循环，但性能差异仍然如此之大.因此，即使您展开，您仍然会受到主要性能偏差的影响.挺有意思的.
The interesting thing is also that the performance difference is still so high although I have already unrolled the loop four times. So even if you unroll, you can still get hit by major performance deviations. Quite interesting.
推荐答案
罪魁祸首:虚假数据依赖(编译器甚至不知道)
在 Sandy/Ivy Bridge 和 Haswell 处理器上，说明:
On Sandy/Ivy Bridge and Haswell processors, the instruction:
popcnt src, dest
似乎对目标寄存器 dest 有错误的依赖性.即使指令只写入它，指令也会等到 dest 准备好后再执行.这种错误的依赖(现在)被英特尔记录为勘误表 HSD146 (Haswell) 和 SKL029 (Skylake)
appears to have a false dependency on the destination register dest. Even though the instruction only writes to it, the instruction will wait until dest is ready before executing. This false dependency is (now) documented by Intel as erratum HSD146 (Haswell) and SKL029 (Skylake)
Skylake 为 lzcnt 和 tzcnt.
Cannon Lake(和 Ice Lake)为 popcnt 修复了这个问题.bsf/bsr 有一个真正的输出依赖:输入=0 时输出未修改.(但无法利用内在函数 - 只有 AMD 记录它，编译器不公开它.)
Skylake fixed this for lzcnt and tzcnt.
Cannon Lake (and Ice Lake) fixed this for popcnt.
bsf/bsr have a true output dependency: output unmodified for input=0. (But no way to take advantage of that with intrinsics - only AMD documents it and compilers don't expose it.)
(是的，这些指令都在在同一个执行单元上运行).
(Yes, these instructions all run on the same execution unit).
这种依赖不仅仅支持来自单个循环迭代的 4 个 popcnt .它可以进行循环迭代，使处理器无法并行化不同的循环迭代.
This dependency doesn't just hold up the 4 popcnts from a single loop iteration. It can carry across loop iterations making it impossible for the processor to parallelize different loop iterations.
unsigned 与 uint64_t 和其他调整不会直接影响问题.但它们会影响将寄存器分配给变量的寄存器分配器.
The unsigned vs. uint64_t and other tweaks don't directly affect the problem. But they influence the register allocator which assigns the registers to the variables.
在您的情况下，速度是粘在(错误)依赖链上的直接结果，具体取决于寄存器分配器决定做什么.
In your case, the speeds are a direct result of what is stuck to the (false) dependency chain depending on what the register allocator decided to do.
- 13 GB/s 有一个链:
popcnt-add-popcnt-popcnt→下一次迭代 - 15 GB/s 有一个链:
popcnt-add-popcnt-add→下一次迭代 - 20 GB/s 有一条链:
popcnt-popcnt→下一次迭代 - 26 GB/s 有一个链:
popcnt-popcnt→下一次迭代
- 13 GB/s has a chain:
popcnt-add-popcnt-popcnt→ next iteration - 15 GB/s has a chain:
popcnt-add-popcnt-add→ next iteration - 20 GB/s has a chain:
popcnt-popcnt→ next iteration - 26 GB/s has a chain:
popcnt-popcnt→ next iteration
20 GB/s 和 26 GB/s 之间的差异似乎是间接寻址的小瑕疵.无论哪种方式，一旦您达到此速度，处理器就会开始遇到其他瓶颈.
The difference between 20 GB/s and 26 GB/s seems to be a minor artifact of the indirect addressing. Either way, the processor starts to hit other bottlenecks once you reach this speed.
为了测试这一点，我使用内联汇编绕过编译器并准确获得我想要的汇编.我还拆分了 count 变量以打破所有其他可能会干扰基准测试的依赖项.
To test this, I used inline assembly to bypass the compiler and get exactly the assembly I want. I also split up the count variable to break all other dependencies that might mess with the benchmarks.
结果如下:
Sandy Bridge Xeon @ 3.5 GHz:(完整的测试代码可以在底部找到)
Sandy Bridge Xeon @ 3.5 GHz: (full test code can be found at the bottom)
- GCC 4.6.3:
g++ popcnt.cpp -std=c++0x -O3 -save-temps -march=native - Ubuntu 12
不同的寄存器:18.6195 GB/s
.L4:
movq (%rbx,%rax,8), %r8
movq 8(%rbx,%rax,8), %r9
movq 16(%rbx,%rax,8), %r10
movq 24(%rbx,%rax,8), %r11
addq $4, %rax
popcnt %r8, %r8
add %r8, %rdx
popcnt %r9, %r9
add %r9, %rcx
popcnt %r10, %r10
add %r10, %rdi
popcnt %r11, %r11
add %r11, %rsi
cmpq $131072, %rax
jne .L4
同一个寄存器:8.49272 GB/s
.L9:
movq (%rbx,%rdx,8), %r9
movq 8(%rbx,%rdx,8), %r10
movq 16(%rbx,%rdx,8), %r11
movq 24(%rbx,%rdx,8), %rbp
addq $4, %rdx
# This time reuse "rax" for all the popcnts.
popcnt %r9, %rax
add %rax, %rcx
popcnt %r10, %rax
add %rax, %rsi
popcnt %r11, %rax
add %rax, %r8
popcnt %rbp, %rax
add %rax, %rdi
cmpq $131072, %rdx
jne .L9
同一个寄存器断链:17.8869 GB/s
.L14:
movq (%rbx,%rdx,8), %r9
movq 8(%rbx,%rdx,8), %r10
movq 16(%rbx,%rdx,8), %r11
movq 24(%rbx,%rdx,8), %rbp
addq $4, %rdx
# Reuse "rax" for all the popcnts.
xor %rax, %rax # Break the cross-iteration dependency by zeroing "rax".
popcnt %r9, %rax
add %rax, %rcx
popcnt %r10, %rax
add %rax, %rsi
popcnt %r11, %rax
add %rax, %r8
popcnt %rbp, %rax
add %rax, %rdi
cmpq $131072, %rdx
jne .L14
<小时>
那么编译器出了什么问题?
似乎 GCC 和 Visual Studio 都不知道 popcnt 有这样一个错误的依赖关系.然而，这些错误的依赖并不少见.只是编译器是否意识到这一点.
It seems that neither GCC nor Visual Studio are aware that popcnt has such a false dependency. Nevertheless, these false dependencies aren't uncommon. It's just a matter of whether the compiler is aware of it.
popcnt 并不是最常用的指令.因此，主要编译器可能会错过这样的事情并不奇怪.似乎也没有任何地方提到这个问题的文档.如果英特尔不公开，那么外界不会知道，除非有人偶然遇到.
popcnt isn't exactly the most used instruction. So it's not really a surprise that a major compiler could miss something like this. There also appears to be no documentation anywhere that mentions this problem. If Intel doesn't disclose it, then nobody outside will know until someone runs into it by chance.
(更新: 从 4.9 版开始.2，GCC 意识到这种错误依赖，并在启用优化时生成代码来补偿它.来自其他供应商的主要编译器，包括 Clang、MSVC，甚至英特尔自己的 ICC 还没有意识到这种微架构错误并且不会发出补偿它的代码.)
(Update: As of version 4.9.2, GCC is aware of this false-dependency and generates code to compensate it when optimizations are enabled. Major compilers from other vendors, including Clang, MSVC, and even Intel's own ICC are not yet aware of this microarchitectural erratum and will not emit code that compensates for it.)
为什么 CPU 会有这种虚假的依赖?
我们可以推测:它与 bsf/bsr 运行在相同的执行单元上，do 具有输出依赖性.(POPCNT 是如何在硬件中实现的?).对于这些指令，英特尔将 input=0 的整数结果记录为未定义"(ZF=1)，但英特尔硬件实际上提供了更强大的保证，以避免破坏旧软件:输出未修改.AMD 记录了这种行为.
We can speculate: it runs on the same execution unit as bsf / bsr which do have an output dependency. (How is POPCNT implemented in hardware?). For those instructions, Intel documents the integer result for input=0 as "undefined" (with ZF=1), but Intel hardware actually gives a stronger guarantee to avoid breaking old software: output unmodified. AMD documents this behaviour.
想必让这个执行单元的一些 uops 依赖于输出但其他的不是.
Presumably it was somehow inconvenient to make some uops for this execution unit dependent on the output but others not.
AMD 处理器似乎没有这种错误依赖.
AMD processors do not appear to have this false dependency.
完整的测试代码如下供参考:
The full test code is below for reference:
#include <iostream>
#include <chrono>
#include <x86intrin.h>
int main(int argc, char* argv[]) {
using namespace std;
uint64_t size=1<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer=reinterpret_cast<char*>(buffer);
for (unsigned i=0;i<size;++i) charbuffer[i]=rand()%256;
uint64_t count,duration;
chrono::time_point<chrono::system_clock> startP,endP;
{
uint64_t c0 = 0;
uint64_t c1 = 0;
uint64_t c2 = 0;
uint64_t c3 = 0;
startP = chrono::system_clock::now();
for( unsigned k = 0; k < 10000; k++){
for (uint64_t i=0;i<size/8;i+=4) {
uint64_t r0 = buffer[i + 0];
uint64_t r1 = buffer[i + 1];
uint64_t r2 = buffer[i + 2];
uint64_t r3 = buffer[i + 3];
__asm__(
"popcnt %4, %4
"
"add %4, %0
"
"popcnt %5, %5
"
"add %5, %1
"
"popcnt %6, %6
"
"add %6, %2
"
"popcnt %7, %7
"
"add %7, %3
"
: "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
: "r" (r0), "r" (r1), "r" (r2), "r" (r3)
);
}
}
count = c0 + c1 + c2 + c3;
endP = chrono::system_clock::now();
duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "No Chain " << count << ' ' << (duration/1.0E9) << " sec "
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
{
uint64_t c0 = 0;
uint64_t c1 = 0;
uint64_t c2 = 0;
uint64_t c3 = 0;
startP = chrono::system_clock::now();
for( unsigned k = 0; k < 10000; k++){
for (uint64_t i=0;i<size/8;i+=4) {
uint64_t r0 = buffer[i + 0];
uint64_t r1 = buffer[i + 1];
uint64_t r2 = buffer[i + 2];
uint64_t r3 = buffer[i + 3];
__asm__(
"popcnt %4, %%rax
"
"add %%rax, %0
"
"popcnt %5, %%rax
"
"add %%rax, %1
"
"popcnt %6, %%rax
"
"add %%rax, %2
"
"popcnt %7, %%rax
"
"add %%rax, %3
"
: "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
: "r" (r0), "r" (r1), "r" (r2), "r" (r3)
: "rax"
);
}
}
count = c0 + c1 + c2 + c3;
endP = chrono::system_clock::now();
duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "Chain 4 " << count << ' ' << (duration/1.0E9) << " sec "
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
{
uint64_t c0 = 0;
uint64_t c1 = 0;
uint64_t c2 = 0;
uint64_t c3 = 0;
startP = chrono::system_clock::now();
for( unsigned k = 0; k < 10000; k++){
for (uint64_t i=0;i<size/8;i+=4) {
uint64_t r0 = buffer[i + 0];
uint64_t r1 = buffer[i + 1];
uint64_t r2 = buffer[i + 2];
uint64_t r3 = buffer[i + 3];
__asm__(
"xor %%rax, %%rax
" // <--- Break the chain.
"popcnt %4, %%rax
"
"add %%rax, %0
"
"popcnt %5, %%rax
"
"add %%rax, %1
"
"popcnt %6, %%rax
"
"add %%rax, %2
"
"popcnt %7, %%rax
"
"add %%rax, %3
"
: "+r" (c0), "+r" (c1), "+r" (c2), "+r" (c3)
: "r" (r0), "r" (r1), "r" (r2), "r" (r3)
: "rax"
);
}
}
count = c0 + c1 + c2 + c3;
endP = chrono::system_clock::now();
duration=chrono::duration_cast<std::chrono::nanoseconds>(endP-startP).count();
cout << "Broken Chain " << count << ' ' << (duration/1.0E9) << " sec "
<< (10000.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}
<小时>
一个同样有趣的基准可以在这里找到:http://pastebin.com/kbzgL8si
该基准测试改变了(假)依赖链中 popcnt 的数量.
False Chain 0: 41959360000 0.57748 sec 18.1578 GB/s
False Chain 1: 41959360000 0.585398 sec 17.9122 GB/s
False Chain 2: 41959360000 0.645483 sec 16.2448 GB/s
False Chain 3: 41959360000 0.929718 sec 11.2784 GB/s
False Chain 4: 41959360000 1.23572 sec 8.48557 GB/s
这篇关于用 64 位替换 32 位循环计数器会在 Intel CPU 上使用 _mm_popcnt_u64 引入疯狂的性能偏差的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
