为什么处理排序数组比处理未排序数组更快？
这是一段看似非常特殊的C ++代码。出于某些奇怪的原因，奇迹般地对数据进行排序使代码快了近六倍。
#include <algorithm>
#include <ctime>
#include <iostream>
int main()
{
// Generate data
const unsigned arraySize = 32768;
int data[arraySize];
for (unsigned c = 0; c < arraySize; ++c)
data[c] = std::rand() % 256;
// !!! With this, the next loop runs faster
std::sort(data, data + arraySize);
// Test
clock_t start = clock();
long long sum = 0;
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
std::cout << elapsedTime << std::endl;
std::cout << "sum = " << sum << std::endl;
}
- 如果没有
std::sort(data, data + arraySize);，代码将在11.54秒内运行。 - 使用排序后的数据，代码运行1.93秒。
最初，我认为这可能只是一种语言或编译器异常。所以我在Java中尝试过它。
import java.util.Arrays;
import java.util.Random;
public class Main
{
public static void main(String[] args)
{
// Generate data
int arraySize = 32768;
int data[] = new int[arraySize];
Random rnd = new Random(0);
for (int c = 0; c < arraySize; ++c)
data[c] = rnd.nextInt() % 256;
// !!! With this, the next loop runs faster
Arrays.sort(data);
// Test
long start = System.nanoTime();
long sum = 0;
for (int i = 0; i < 100000; ++i)
{
// Primary loop
for (int c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
System.out.println((System.nanoTime() - start) / 1000000000.0);
System.out.println("sum = " + sum);
}
}
有点相似但不太极端的结果。
我的第一个想法是排序将数据带入缓存，但后来我认为这是多么愚蠢，因为数组刚刚生成。
- 发生了什么事？
- 为什么处理排序数组比处理未排序数组更快？
- 代码总结了一些独立的术语，顺序无关紧要。
27 个答案:
答案 0 :(得分：30199)
您是branch prediction失败的受害者。
什么是分支预测？
考虑一个铁路交界处：
Mecanismo的 Image，来自Wikimedia Commons。在CC-By-SA 3.0许可下使用。
现在为了争论，假设这是在19世纪 - 在长途或无线电通信之前。
你是一个交叉路口的经营者，你听到火车来了。你不知道应该走哪条路。你停下火车去询问司机他们想要的方向。然后适当地设置开关。
火车很重，惯性很大。所以他们需要永远启动并放慢速度。
有更好的方法吗？你猜猜火车将朝哪个方向前进！
- 如果你猜对了，那就继续。
- 如果你猜错了，机长会停下来，然后向你大喊大叫，然后翻转开关。然后它可以从另一条路径重启。
如果你每次都猜对了，火车将永远不会停下来。
如果您经常猜错，列车将花费大量时间停止，备份和重新启动。
考虑一个if语句：在处理器级别，它是一个分支指令：
你是一个处理器，你看到一个分支。你不知道它会走哪条路。你是做什么？您暂停执行并等待前面的指令完成。然后继续沿着正确的道路前进。
现代处理器很复杂，管道很长。所以他们永远都要热身＃34;和＆＃34;放慢速度＆＃34;。
有更好的方法吗？你猜这个分支会走向哪个方向！
- 如果你猜对了，你继续执行。
- 如果您猜错了，则需要刷新管道并回滚到分支。然后你可以重新启动另一条路径。
如果您每次都认为正确，执行将永远不会停止。
如果您经常猜错，则会花费大量时间停止，回滚和重新启动。
这是分支预测。我承认这不是最好的比喻，因为火车只能用旗子发出信号指示。但是在计算机中，处理器并不知道分支到最后一刻的方向。
那么你如何战略性地猜测火车必须备份并沿着另一条路走下去的次数呢？你看看过去的历史！如果火车99％的时间都离开，那么你猜对了。如果它交替，那么你交替猜测。如果它每三次走一条路，你就猜相同......
换句话说，您尝试识别模式并遵循它。 这或多或少是分支预测变量的工作方式。
大多数应用程序具有良好的分支。因此，现代分支预测器通常将达到> 90％的命中率。但是当面对不可预测的分支而没有可识别的模式时，分支预测器实际上是无用的。
进一步阅读："Branch predictor" article on Wikipedia。
如上所述，罪魁祸首是if语句：
if (data[c] >= 128)
sum += data[c];
请注意，数据均匀分布在0到255之间。当数据排序时，大约前半部分的迭代不会进入if语句。之后，他们都将进入if语句。
这对分支预测器非常友好，因为分支连续多次向同一方向移动。即使是简单的饱和计数器也会正确地预测分支，除了在切换方向后的几次迭代。
快速可视化：
T = branch taken
N = branch not taken
data[] = 0, 1, 2, 3, 4, ... 126, 127, 128, 129, 130, ... 250, 251, 252, ...
branch = N N N N N ... N N T T T ... T T T ...
= NNNNNNNNNNNN ... NNNNNNNTTTTTTTTT ... TTTTTTTTTT (easy to predict)
然而，当数据完全随机时，分支预测器变得无用，因为它无法预测随机数据。因此，可能会有大约50％的错误预测（并不比随机猜测更好）。
data[] = 226, 185, 125, 158, 198, 144, 217, 79, 202, 118, 14, 150, 177, 182, 133, ...
branch = T, T, N, T, T, T, T, N, T, N, N, T, T, T, N ...
= TTNTTTTNTNNTTTN ... (completely random - hard to predict)
那可以做些什么？
如果编译器无法将分支优化为条件移动，那么如果您愿意牺牲性能的可读性，可以尝试一些黑客攻击。
替换：
if (data[c] >= 128)
sum += data[c];
使用：
int t = (data[c] - 128) >> 31;
sum += ~t & data[c];
这消除了分支并用一些按位操作替换它。
（请注意，此hack并不严格等同于原始的if语句。但在这种情况下，它对data[]的所有输入值都有效。）
基准：Core i7 920 @ 3.5 GHz
C ++ - Visual Studio 2010 - x64发布
// Branch - Random
seconds = 11.777
// Branch - Sorted
seconds = 2.352
// Branchless - Random
seconds = 2.564
// Branchless - Sorted
seconds = 2.587
Java - NetBeans 7.1.1 JDK 7 - x64
// Branch - Random
seconds = 10.93293813
// Branch - Sorted
seconds = 5.643797077
// Branchless - Random
seconds = 3.113581453
// Branchless - Sorted
seconds = 3.186068823
观察：
- 使用分支机构：已排序和未排序的数据之间存在巨大差异。
- 使用Hack：排序数据和未排序数据之间没有区别。
- 在C ++的情况下，当数据被排序时，hack实际上比分支慢一点。
一般的经验法则是避免关键循环中的数据相关分支（例如本例中）。
<强>更新
-
在x64上使用
-O3或-ftree-vectorize的GCC 4.6.1能够生成条件移动。因此，排序数据和未排序数据之间没有区别 - 两者都很快。 -
即使在
/Ox下，VC ++ 2010也无法为此分支生成条件移动。 -
Intel C++ Compiler（ICC）11做了一些奇迹。它interchanges the two loops，从而将不可预测的分支提升到外环。因此，它不仅能够免受错误预测的影响，而且速度也是VC ++和GCC能够产生的速度的两倍！换句话说，ICC利用测试循环来击败基准......
-
如果你给英特尔编译器提供无分支代码，它只是向右矢量化它...并且与分支一样快（使用循环交换）。
这表明即使是成熟的现代编译器在优化代码的能力方面也会有很大差异......
答案 1 :(得分：3896)
分支预测。
对于排序数组，条件data[c] >= 128对于条纹值首先为false，对于所有后续值，条件为true。这很容易预测。使用未排序的数组，您需要支付分支成本。
答案 2 :(得分：3134)
在对数据进行排序时性能显着提高的原因是删除了分支预测惩罚，正如Mysticial's answer中精美解释的那样。
现在，如果我们看一下代码
if (data[c] >= 128)
sum += data[c];
我们可以发现这个特定if... else...分支的含义是在条件满足时添加一些东西。这种类型的分支可以很容易地转换为条件移动语句，该语句将被编译为cmovl系统中的条件移动指令：x86。分支以及潜在的分支预测惩罚被删除。
在C中，C++，将直接编译（没有任何优化）到x86中的条件移动指令的语句是三元运算符... ? ... : ... 。因此，我们将上述语句重写为等效语句：
sum += data[c] >=128 ? data[c] : 0;
在保持可读性的同时，我们可以检查加速因子。
在英特尔Core i7 - 2600K @ 3.4 GHz和Visual Studio 2010发布模式下，基准是（从Mysticial复制的格式）：
<强> 86
// Branch - Random
seconds = 8.885
// Branch - Sorted
seconds = 1.528
// Branchless - Random
seconds = 3.716
// Branchless - Sorted
seconds = 3.71
<强> 64
// Branch - Random
seconds = 11.302
// Branch - Sorted
seconds = 1.830
// Branchless - Random
seconds = 2.736
// Branchless - Sorted
seconds = 2.737
结果在多次测试中都很稳健。当分支结果不可预测时，我们得到了很大的加速，但是当它是可预测的时候我们会受到一点点的影响。实际上，在使用条件移动时，无论数据模式如何，性能都是相同的。
现在让我们通过调查他们生成的x86程序集来更仔细地看一下。为简单起见，我们使用两个函数max1和max2。
max1使用条件分支if... else ...：
int max1(int a, int b) {
if (a > b)
return a;
else
return b;
}
max2使用三元运算符... ? ... : ...：
int max2(int a, int b) {
return a > b ? a : b;
}
在x86-64计算机上，GCC -S生成下面的程序集。
:max1
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), %eax
cmpl -8(%rbp), %eax
jle .L2
movl -4(%rbp), %eax
movl %eax, -12(%rbp)
jmp .L4
.L2:
movl -8(%rbp), %eax
movl %eax, -12(%rbp)
.L4:
movl -12(%rbp), %eax
leave
ret
:max2
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), %eax
cmpl %eax, -8(%rbp)
cmovge -8(%rbp), %eax
leave
ret
max2， cmovge使用的代码要少得多。但真正的好处是max2不涉及分支跳转jmp，如果预测结果不正确，则会对性能造成重大影响。
那为什么条件移动的表现更好？
在典型的x86处理器中，指令的执行分为几个阶段。粗略地说，我们有不同的硬件来处理不同的阶段。因此，我们不必等待一条指令完成开始新指令。这称为 pipelining 。
在分支情况下，以下指令由前一个指令决定，因此我们不能进行流水线操作。我们必须等待或预测。
在条件移动的情况下，执行条件移动指令分为几个阶段，但像Fetch和Decode这样的早期阶段不依赖于前一个指令的结果;只有后期才需要结果。因此，我们等待一个指令执行时间的一小部分。这就是为什么当预测很容易时，条件移动版本比分支慢。
这本书 Computer Systems: A Programmer's Perspective, second edition 详细解释了这一点。您可以查看第3.6.6节，了解条件移动指令，整个第4章用于处理器架构，以及第5.11.2节有关分支预测和误预测的特殊处理处罚
有时，一些现代编译器可以优化我们的代码以便以更好的性能进行汇编，有时一些编译器不能（有问题的代码使用Visual Studio的本机编译器）。在不可预测的情况下了解分支和条件移动之间的性能差异可以帮助我们在场景变得如此复杂以至于编译器无法自动优化它们时编写具有更好性能的代码。
答案 3 :(得分：2150)
如果您对可以对此代码进行更多优化感到好奇，请考虑以下事项：
从原始循环开始：
for (unsigned i = 0; i < 100000; ++i)
{
for (unsigned j = 0; j < arraySize; ++j)
{
if (data[j] >= 128)
sum += data[j];
}
}
通过循环交换，我们可以安全地将此循环更改为：
for (unsigned j = 0; j < arraySize; ++j)
{
for (unsigned i = 0; i < 100000; ++i)
{
if (data[j] >= 128)
sum += data[j];
}
}
然后，您可以看到if条件在i循环执行期间保持不变，因此您可以将if提升出来：
for (unsigned j = 0; j < arraySize; ++j)
{
if (data[j] >= 128)
{
for (unsigned i = 0; i < 100000; ++i)
{
sum += data[j];
}
}
}
然后，您会看到内部循环可以折叠成一个单独的表达式，假设浮点模型允许它（例如，抛出/fp:fast）
for (unsigned j = 0; j < arraySize; ++j)
{
if (data[j] >= 128)
{
sum += data[j] * 100000;
}
}
那个比之前快10万倍。
答案 4 :(得分：1793)
毫无疑问，我们中的一些人会对识别对CPU的分支预测器有问题的代码感兴趣。 Valgrind工具cachegrind具有分支预测模拟器，使用--branch-sim=yes标志启用。在这个问题的例子中运行它，外部循环的数量减少到10000并用g++编译，给出了这些结果：
<强>排序
==32551== Branches: 656,645,130 ( 656,609,208 cond + 35,922 ind)
==32551== Mispredicts: 169,556 ( 169,095 cond + 461 ind)
==32551== Mispred rate: 0.0% ( 0.0% + 1.2% )
<强>未排序：
==32555== Branches: 655,996,082 ( 655,960,160 cond + 35,922 ind)
==32555== Mispredicts: 164,073,152 ( 164,072,692 cond + 460 ind)
==32555== Mispred rate: 25.0% ( 25.0% + 1.2% )
深入研究cg_annotate生成的逐行输出，我们看到有问题的循环：
<强>排序
Bc Bcm Bi Bim
10,001 4 0 0 for (unsigned i = 0; i < 10000; ++i)
. . . . {
. . . . // primary loop
327,690,000 10,016 0 0 for (unsigned c = 0; c < arraySize; ++c)
. . . . {
327,680,000 10,006 0 0 if (data[c] >= 128)
0 0 0 0 sum += data[c];
. . . . }
. . . . }
<强>未排序：
Bc Bcm Bi Bim
10,001 4 0 0 for (unsigned i = 0; i < 10000; ++i)
. . . . {
. . . . // primary loop
327,690,000 10,038 0 0 for (unsigned c = 0; c < arraySize; ++c)
. . . . {
327,680,000 164,050,007 0 0 if (data[c] >= 128)
0 0 0 0 sum += data[c];
. . . . }
. . . . }
这使您可以轻松识别有问题的行 - 在未排序的版本中，if (data[c] >= 128)行在cachegrind的分支预测模型下导致164,050,007个错误预测的条件分支（Bcm），而它只导致10,006排序版本。
或者，在Linux上，您可以使用性能计数器子系统来完成相同的任务，但使用CPU计数器具有本机性能。
perf stat ./sumtest_sorted
<强>排序
Performance counter stats for './sumtest_sorted':
11808.095776 task-clock # 0.998 CPUs utilized
1,062 context-switches # 0.090 K/sec
14 CPU-migrations # 0.001 K/sec
337 page-faults # 0.029 K/sec
26,487,882,764 cycles # 2.243 GHz
41,025,654,322 instructions # 1.55 insns per cycle
6,558,871,379 branches # 555.455 M/sec
567,204 branch-misses # 0.01% of all branches
11.827228330 seconds time elapsed
<强>未排序：
Performance counter stats for './sumtest_unsorted':
28877.954344 task-clock # 0.998 CPUs utilized
2,584 context-switches # 0.089 K/sec
18 CPU-migrations # 0.001 K/sec
335 page-faults # 0.012 K/sec
65,076,127,595 cycles # 2.253 GHz
41,032,528,741 instructions # 0.63 insns per cycle
6,560,579,013 branches # 227.183 M/sec
1,646,394,749 branch-misses # 25.10% of all branches
28.935500947 seconds time elapsed
它也可以使用反汇编进行源代码注释。
perf record -e branch-misses ./sumtest_unsorted
perf annotate -d sumtest_unsorted
Percent | Source code & Disassembly of sumtest_unsorted
------------------------------------------------
...
: sum += data[c];
0.00 : 400a1a: mov -0x14(%rbp),%eax
39.97 : 400a1d: mov %eax,%eax
5.31 : 400a1f: mov -0x20040(%rbp,%rax,4),%eax
4.60 : 400a26: cltq
0.00 : 400a28: add %rax,-0x30(%rbp)
...
有关详细信息，请参阅the performance tutorial。
答案 5 :(得分：1251)
我刚读了这个问题及其答案，我觉得答案遗失了。
消除我发现在托管语言中工作特别好的分支预测的一种常用方法是查找表而不是使用分支（尽管我在这种情况下没有测试过它）。
这种方法一般适用于：
- 这是一张小桌子，可能会被缓存在处理器中，
- 您正在以非常紧凑的循环运行和/或处理器可以预加载数据。
背景和原因
从处理器的角度来看，你的记忆很慢。为了弥补速度的差异，处理器（L1 / L2缓存）中内置了几个缓存。所以想象一下，你正在进行漂亮的计算并弄清楚你需要一块内存。处理器将获得其“加载”操作并将内存加载到缓存中 - 然后使用缓存执行其余计算。由于内存相对较慢，因此“加载”会降低程序的速度。
与分支预测一样，这在Pentium处理器中进行了优化：处理器预测它需要加载一段数据并尝试在操作实际到达缓存之前将其加载到缓存中。正如我们已经看到的那样，分支预测有时会出现严重错误 - 在最坏的情况下，您需要返回并实际等待内存负载，这将需要永远（换句话说：分支预测失败很糟糕，分支预测失败后的内存负载非常可怕！）。
幸运的是，如果内存访问模式是可预测的，处理器会将其加载到快速缓存中，一切都很好。
我们需要知道的第一件事是 small ？虽然较小通常更好，但经验法则是坚持大于＆lt; = 4096字节的查找表。作为上限：如果您的查找表大于64K，则可能值得重新考虑。
构建表格
所以我们已经发现我们可以创建一个小表。接下来要做的是获得一个查找功能。查找函数通常是使用几个基本整数运算的小函数（和，或者，xor，shift，add，remove和multiply）。您希望通过查找功能将您的输入转换为表格中的某种“唯一键”，然后只需为您提供所需工作的答案。
在这种情况下：＆gt; = 128表示我们可以保留该值，＆lt; 128意味着我们摆脱它。最简单的方法是使用'AND'：如果我们保留它，我们和7FFFFFFF;如果我们想要摆脱它，我们和它的0.注意另外128是2的幂 - 所以我们可以继续制作一个32768/128整数的表并填充一个零和很多7FFFFFFFF的。
托管语言
您可能想知道为什么这在托管语言中运行良好。毕竟，托管语言使用分支检查数组的边界，以确保您不会陷入困境......
嗯，不完全......： - ）
为管理语言消除此分支已经做了很多工作。例如：
for (int i = 0; i < array.Length; ++i)
{
// Use array[i]
}
在这种情况下，编译器显然不会遇到边界条件。至少Microsoft JIT编译器（但我希望Java做类似的事情）会注意到这一点，并完全删除检查。哇，这意味着没有分支。同样，它将处理其他明显的案例。
如果您在托管语言中查找时遇到问题 - 关键是在查找函数中添加& 0x[something]FFF以使边界检查可预测 - 并观察它更快。
此案例的结果
// Generate data
int arraySize = 32768;
int[] data = new int[arraySize];
Random random = new Random(0);
for (int c = 0; c < arraySize; ++c)
{
data[c] = random.Next(256);
}
/*To keep the spirit of the code intact, I'll make a separate lookup table
(I assume we cannot modify 'data' or the number of loops)*/
int[] lookup = new int[256];
for (int c = 0; c < 256; ++c)
{
lookup[c] = (c >= 128) ? c : 0;
}
// Test
DateTime startTime = System.DateTime.Now;
long sum = 0;
for (int i = 0; i < 100000; ++i)
{
// Primary loop
for (int j = 0; j < arraySize; ++j)
{
/* Here you basically want to use simple operations - so no
random branches, but things like &, |, *, -, +, etc. are fine. */
sum += lookup[data[j]];
}
}
DateTime endTime = System.DateTime.Now;
Console.WriteLine(endTime - startTime);
Console.WriteLine("sum = " + sum);
Console.ReadLine();
答案 6 :(得分：1122)
当数组排序时，数据在0到255之间分配，在迭代的前半部分周围不会输入if - 语句（if语句在下面共享）。
if (data[c] >= 128)
sum += data[c];
问题是：在某些情况下，如果排序数据，上述语句不执行的原因是什么？这是“分支预测器”。分支预测器是一种数字电路，它试图猜测分支（例如if-then-else结构）将以何种方式确定。分支预测器的目的是改善指令流水线中的流量。分支预测器在实现高效性能方面发挥着关键作用！
让我们做一些基准测试以更好地理解
if语句的表现取决于其条件是否具有可预测的模式。如果条件始终为真或始终为假，则处理器中的分支预测逻辑将获取模式。另一方面，如果模式不可预测，if - 语句将会更加昂贵。
让我们用不同的条件来衡量这个循环的性能：
for (int i = 0; i < max; i++)
if (condition)
sum++;
以下是具有不同真假模式的循环的时间：
Condition Pattern Time (ms)
-------------------------------------------------------
(i & 0×80000000) == 0 T repeated 322
(i & 0xffffffff) == 0 F repeated 276
(i & 1) == 0 TF alternating 760
(i & 3) == 0 TFFFTFFF… 513
(i & 2) == 0 TTFFTTFF… 1675
(i & 4) == 0 TTTTFFFFTTTTFFFF… 1275
(i & 8) == 0 8T 8F 8T 8F … 752
(i & 16) == 0 16T 16F 16T 16F … 490
“错误”真假模式可以使if - 语句比“良好”模式慢六倍！当然，哪种模式好，哪种模式不好取决于编译器和特定处理器生成的确切指令。
因此，分支预测对绩效的影响毫无疑问！
答案 7 :(得分：1044)
避免分支预测错误的一种方法是构建查找表，并使用数据对其进行索引。 Stefan de Bruijn在他的回答中讨论了这个问题。
但在这种情况下，我们知道值在[0,255]范围内，我们只关心值＆gt; = 128.这意味着我们可以轻松提取一个位，告诉我们是否需要值或不是：通过将数据移位到右边7位，我们留下0位或1位，我们只想在有1位时添加数值。我们把这个称为“决策位”。
通过使用决策位的0/1值作为数组的索引，无论数据是排序还是未排序，我们都可以生成同样快的代码。我们的代码总是会添加一个值，但是当决策位为0时，我们会将值添加到我们不关心的地方。这是代码：
// Test
clock_t start = clock();
long long a[] = {0, 0};
long long sum;
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
int j = (data[c] >> 7);
a[j] += data[c];
}
}
double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
sum = a[1];
此代码浪费了一半的添加但从未有分支预测失败。随机数据的速度比具有实际if语句的版本快得多。
但在我的测试中，显式查找表略快于此，可能是因为索引到查找表的速度比位移略快。这显示了我的代码如何设置和使用查找表（在代码中对于“LookUp Table”无意义地称为lut）。这是C ++代码：
// Declare and then fill in the lookup table
int lut[256];
for (unsigned c = 0; c < 256; ++c)
lut[c] = (c >= 128) ? c : 0;
// Use the lookup table after it is built
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
sum += lut[data[c]];
}
}
在这种情况下，查找表只有256个字节，因此它非常适合缓存，而且速度很快。如果数据是24位值并且我们只想要它们中的一半，这种技术将无法正常工作......查找表太大而不实用。另一方面，我们可以结合上面显示的两种技术：首先将位移位，然后索引查找表。对于我们只需要上半部分值的24位值，我们可能将数据右移12位，并为表索引留下12位值。 12位表索引意味着一个包含4096个值的表，这可能是实用的。
索引到数组而不是使用if语句的技术可用于决定使用哪个指针。我看到一个实现二叉树的库，而不是有两个命名指针（pLeft和pRight或其他）有一个长度为2的指针数组，并使用“决策位”技术来决定一个要跟随。例如，而不是：
if (x < node->value)
node = node->pLeft;
else
node = node->pRight;
这个库会做类似的事情：
i = (x < node->value);
node = node->link[i];
以下是此代码的链接：Red Black Trees， Eternal Confuzzled
答案 8 :(得分：944)
在排序的情况下，您可以做得比依靠成功的分支预测或任何无分支比较技巧更好：完全删除分支。
实际上，数组在data < 128的连续区域和data >= 128的另一个区域中分区。因此，您应该找到带有dichotomic search的分区点（使用Lg(arraySize) = 15比较），然后从该点直接累积。
像（未选中）
之类的东西int i= 0, j, k= arraySize;
while (i < k)
{
j= (i + k) >> 1;
if (data[j] >= 128)
k= j;
else
i= j;
}
sum= 0;
for (; i < arraySize; i++)
sum+= data[i];
或稍微混淆
int i, k, j= (i + k) >> 1;
for (i= 0, k= arraySize; i < k; (data[j] >= 128 ? k : i)= j)
j= (i + k) >> 1;
for (sum= 0; i < arraySize; i++)
sum+= data[i];
更快的方法是为排序或未排序提供近似解决方案：sum= 3137536;（假设真正均匀分布，16384个样本，预期值为191.5）： - ）
答案 9 :(得分：768)
由于分支预测，上述行为正在发生。
要理解分支预测，首先必须了解指令管道：
任何指令都分为一系列步骤，以便可以并行执行不同的步骤。这种技术称为指令流水线，用于提高现代处理器的吞吐量。要更好地理解这一点，请参阅此example on Wikipedia。
一般来说，现代处理器有很长的流水线，但为了方便起见，我们只考虑这4个步骤。
- IF - 从内存中获取指令
- ID - 解码指令
- EX - 执行指令
- WB - 写回CPU寄存器
4阶段管道，一般用于2条指令。
回到上述问题，让我们考虑以下说明：
A) if (data[c] >= 128)
/\
/ \
/ \
true / \ false
/ \
/ \
/ \
/ \
B) sum += data[c]; C) for loop or print().
如果没有分支预测，将发生以下情况：
为了执行指令B或指令C，处理器必须等到指令A没有到达流水线中的EX阶段，因为转到指令B或指令C的决定取决于指令A的结果。因此管道将如下所示。
如果条件返回true，则 ：
if条件返回false时：
由于等待指令A的结果，在上述情况下花费的总CPU周期（没有分支预测;对于true和false）是7。
那么什么是分支预测？
分支预测器将尝试猜测分支（if-then-else结构）将以何种方式确定之前。它不会等待指令A到达流水线的EX阶段，但是它会猜测决定并转到该指令（在我们的例子中是B或C）。
如果猜测正确，管道看起来像这样：
如果稍后检测到猜测错误，则丢弃部分执行的指令，并且管道以正确的分支重新开始，从而导致延迟。 在分支错误预测的情况下浪费的时间等于从提取阶段到执行阶段的管道中的阶段的数量。现代微处理器往往具有相当长的流水线，因此误预测延迟在10到20个时钟周期之间。管道越长，对branch predictor的需求就越大。
在OP的代码中，第一次有条件时，分支预测器没有任何基于预测的信息，所以第一次它会随机选择下一条指令。稍后在for循环中，它可以基于历史记录进行预测。 对于按升序排序的数组，有三种可能性：
- 所有元素都小于128
- 所有元素都大于128
- 一些起始新元素小于128，后来大于128
让我们假设预测器将在第一次运行时始终采用真分支。
因此，在第一种情况下，它始终采用真正的分支，因为历史上它的所有预测都是正确的。 在第二种情况下，最初它会预测错误，但经过几次迭代后，它会正确预测。 在第三种情况下，它将最初正确预测，直到元素小于128.之后它将失败一段时间并且当它看到历史中的分支预测失败时正确。
在所有这些情况下，故障的数量会太少，因此，只需要几次就可以丢弃部分执行的指令并重新使用正确的分支，从而减少CPU周期。
但是在随机未排序的数组的情况下，预测将需要丢弃部分执行的指令，并且在大多数情况下重新使用正确的分支，并且与排序的数组相比产生更多的CPU周期。
答案 10 :(得分：671)
官方答案来自
- Intel - Avoiding the Cost of Branch Misprediction
- Intel - Branch and Loop Reorganization to Prevent Mispredicts
- Scientific papers - branch prediction computer architecture
- 书籍：J.L。Hennessy，D.A。帕特森：计算机架构：定量方法
- 科学出版物中的文章：T.Y。 Ye，Y.N。 Patt在分支预测上做了很多这些。
您还可以从这个可爱的diagram中看到为什么分支预测器会混淆。
原始代码中的每个元素都是随机值
data[c] = std::rand() % 256;
所以预测变量将改变为std::rand()打击。
另一方面，一旦它被排序，预测器将首先进入强烈未被采用的状态，当值变为高值时，预测器将在三次运行中通过一直改变从强烈未采用到强服用。
答案 11 :(得分：638)
在同一行（我认为没有任何答案突出显示），有时候（特别是在性能很重要的软件中，比如在Linux内核中）你可以找到一些if语句如下所示：< / p>
if (likely( everything_is_ok ))
{
/* Do something */
}
或类似地：
if (unlikely(very_improbable_condition))
{
/* Do something */
}
likely()和unlikely()实际上都是通过使用类似GCC的__builtin_expect来定义的宏来帮助编译器插入预测代码以支持考虑所提供信息的条件由用户。 GCC支持其他可能改变正在运行的程序行为的内置函数或发出低级指令，如清除缓存等。请参阅通过可用GCC内置函数的this documentation。
通常，这种优化主要在硬实时应用程序或嵌入式系统中找到，其中执行时间很重要且非常重要。例如，如果您正在检查仅发生1/10000000次的错误情况，那么为什么不通知编译器呢？这样，默认情况下，分支预测会假设条件为假。
答案 12 :(得分：606)
C ++中经常使用的布尔运算会在编译的程序中生成许多分支。如果这些分支是在循环内部并且很难预测它们会显着减慢执行速度。布尔变量存储为8位整数，0的值为false，1的值为true。
布尔变量是超定的，因为所有具有布尔变量作为输入的运算符检查输入是否具有除0或1之外的任何其他值，但是具有布尔值作为输出的运算符不会产生否除0或1之外的其他值。这使得使用布尔变量作为输入的操作效率低于必要的。
考虑一下例子：
bool a, b, c, d;
c = a && b;
d = a || b;
这通常由编译器以下列方式实现：
bool a, b, c, d;
if (a != 0) {
if (b != 0) {
c = 1;
}
else {
goto CFALSE;
}
}
else {
CFALSE:
c = 0;
}
if (a == 0) {
if (b == 0) {
d = 0;
}
else {
goto DTRUE;
}
}
else {
DTRUE:
d = 1;
}
这段代码远非最佳。如果误预测，分支机构可能需要很长时间。如果确定操作数没有除0和1之外的其他值，则可以使布尔运算更有效。编译器没有做出这样的假设的原因是，如果变量未初始化或来自未知来源，则变量可能具有其他值。如果a和b已初始化为有效值，或者它们来自生成布尔输出的运算符，则可以优化上述代码。优化的代码如下所示：
char a = 0, b = 1, c, d;
c = a & b;
d = a | b;
char代替bool，以便可以使用按位运算符（&和|）代替布尔运算符（{{1} }和&&）。按位运算符是单个指令，只需一个时钟周期。即使||和|具有除a或b之外的其他值，OR运算符（0）仍然有效。如果操作数具有除1和&之外的其他值，则AND运算符（^）和EXCLUSIVE OR运算符（0）可能会产生不一致的结果。
1不能用于NOT。相反，您可以通过与~进行异或来对已知为0或1的变量进行布尔值NOT：
1可以优化为：
bool a, b;
b = !a;
char a = 0, b;
b = a ^ 1;
是a && b为a & b为b时不应评估的表达式，{p> a将无法替换false不评估&&，b会）。同样，如果&是a || b为a | b时不应评估的表达式，则b无法替换为a。
如果操作数是变量而不是操作数是比较，则使用按位运算符更有利：
true是最佳的（除非您希望bool a; double x, y, z;
a = x > y && z < 5.0;
表达式生成许多分支误预测。）
答案 13 :(得分：285)
这是肯定的！...
分支预测会使逻辑运行速度变慢，因为代码中会发生切换！这就像你要走一条直街或一条有很多转弯的街道，肯定会直接做得更快！...
如果数组已排序，则第一步的条件为false：data[c] >= 128，然后成为到街道尽头的整个路径的真值。这就是你如何更快地完成逻辑的结束。另一方面，使用未排序的数组，需要进行大量的转换和处理，这使得代码运行得更慢......
查看我在下面为您创建的图像。哪条街要快点完成？
因此，以编程方式，分支预测会导致进程变慢...
最后，我们很高兴知道我们有两种分支预测，每种分支预测都会以不同的方式影响您的代码：
<强> 1。静态
<强> 2。动态
第一次微处理器使用静态分支预测 遇到条件分支，动态分支预测是 用于后续执行条件分支代码。
为了有效地编写代码以利用这些代码 规则，在编写 if-else 或切换语句时，请检查最多 首先是常见病例，逐步减少到最不常见的情况。 循环不一定需要任何特殊的代码排序 静态分支预测，仅作为循环迭代器的条件 通常使用。
答案 14 :(得分：264)
这个问题已经多次得到了很好的回答。我还想提请小组注意另一个有趣的分析。
最近这个例子（稍微修改过）也被用来演示如何在Windows上的程序本身中分析一段代码。在此过程中，作者还展示了如何使用结果来确定代码在排序和排序中花费大部分时间的位置。未分类的案例。最后，该文章还展示了如何使用HAL（硬件抽象层）的一个鲜为人知的特征来确定在未排序的情况下发生了多少分支错误预测。
链接在这里： http://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/profile/demo.htm
答案 15 :(得分：180)
正如其他人已经提到的那样，神秘背后的是Branch Predictor。
我不是试图添加一些东西，而是以另一种方式解释这个概念。 维基上有一个简明的介绍，其中包含文本和图表。 我喜欢下面的解释，它使用图表直观地阐述了分支预测器。
在计算机体系结构中，分支预测器是a 试图猜测分支的方式的数字电路（例如 if-then-else结构）将在此之前确定。该 分支预测器的目的是改善流量 指令管道。分支预测因子在其中起着关键作用 在许多现代流水线中实现高效性能 微处理器体系结构，如x86。
双向分支通常使用条件跳转来实现 指令。条件跳转可以是＆＃34;不采取＆＃34;并继续 使用紧随其后的第一个代码分支执行 在条件跳转之后，或者它可以被采取＆＃34;然后跳到一个 程序存储器中不同的位置，代码的第二个分支是 存储。目前尚不清楚是否会有条件跳跃 在计算条件之前采取或不采取 条件跳转已经过了指令中的执行阶段 管道（见图1）。
根据描述的场景，我编写了一个动画演示，以展示在不同情况下如何在管道中执行指令。
- 没有分支预测器。
- 使用分支预测器并且不进行条件跳转。让我们假设预测不采取条件跳转。
- 使用分支预测器并进行条件跳转。让我们假设预测不采取条件跳转。
如果没有分支预测，处理器将不得不等到 条件跳转指令已经过了执行阶段 下一条指令可以进入管道中的提取阶段。
该示例包含三条指令，第一条是条件跳转指令。后两条指令可以进入流水线，直到执行条件跳转指令。
完成3条指令需要9个时钟周期。
完成3条指令需要7个时钟周期。
完成3条指令需要9个时钟周期。
在分支机构错误预测的情况下浪费的时间等于 从提取阶段到管道的管道中的阶段数 执行阶段。现代微处理器往往需要很长时间 管道使错误预测延迟在10到20个时钟之间 周期。因此，延长管道时间增加了对a的需求 更高级的分支预测器。
正如您所看到的，我们似乎没有理由不使用分支预测器。
这是一个非常简单的演示，阐明了分支预测器的基本部分。如果这些GIF很烦人，请随时将它们从答案中删除，访问者也可以从git获取演示
答案 16 :(得分：171)
分支预测增益！
重要的是要理解分支错误预测并不会减慢程序的速度。错过预测的成本就好像分支预测不存在并且您等待表达式的评估以决定运行什么代码（在下一段中进一步解释）。
if (expression)
{
// Run 1
} else {
// Run 2
}
每当有if-else \ switch语句时，必须对表达式求值以确定应该执行哪个块。在编译器生成的汇编代码中，插入了条件branch指令。
分支指令可能导致计算机开始执行不同的指令序列，从而偏离其按顺序执行指令的默认行为（即如果表达式为false，则程序跳过if块的代码）取决于某些条件，这是我们案例中的表达评估。
话虽如此，编译器会在实际评估之前尝试预测结果。它会从if块中获取指令，如果表达式是真的，那就太棒了！我们获得了评估它并在代码中取得进展所花费的时间;如果没有，那么我们运行错误的代码，刷新管道，并运行正确的块。
可视化：
让我们说你需要选择路线1或路线2.等待你的伴侣检查地图，你已停在##并等待，或者你可以选择路线1，如果你很幸运（路线） 1是正确的路线），那么你没有必要等待你的伴侣检查地图（你节省了检查地图的时间），否则你只需要回头。
虽然冲洗管道速度非常快，但现在采取这种赌博是值得的。预测排序数据或变化缓慢的数据总是比预测快速变化更容易和更好。
O Route 1 /-------------------------------
/|\ /
| ---------##/
/ \ \
\
Route 2 \--------------------------------
答案 17 :(得分：115)
关于分支预测。它是什么？
-
分支预测器是古老的性能改进技术之一，它仍然与现代建筑相关。虽然简单的预测技术提供快速查找和功率效率，但它们具有较高的误预测率。
-
另一方面，复杂的分支预测 - 无论是基于神经的还是两级分支预测的变体 - 提供更好的预测准确性，但它们消耗更多的功率和复杂性呈指数增长。
-
除此之外，在复杂的预测技术中，预测分支所花费的时间本身非常高，从2到5个周期 - 这与实际分支的执行时间相当。
< / LI> -
分支预测本质上是一个优化（最小化）问题，其重点是以最少的资源实现最低可能的未命中率，低功耗和低复杂度。
确实有三种不同的分支：
转发条件分支 - 根据运行时条件，PC（程序计数器）更改为指向指令流中的转发地址。
后向条件分支 - PC在指令流中更改为指向后方。该分支基于某些条件，例如，当循环结束时的测试表明循环应该再次执行时，向后分支到程序循环的开头。
无条件分支 - 这包括没有特定条件的跳转，过程调用和返回。例如，无条件跳转指令可能用汇编语言编码为＆＃34; jmp＆＃34;，并且指令流必须立即定向到跳转指令指向的目标位置，而条件跳转可能是编码为＆＃34; jmpne＆＃34;只有在前一个＆＃34;比较＆＃34;中的两个值的比较结果时，才会重定向指令流。说明显示值不相等。 （x86体系结构使用的分段寻址方案增加了额外的复杂性，因为跳转可以是＆＃34;接近＆＃34;（在一个段内）或＆＃34; far＆＃34;（在段外）。每种类型都有对分支预测算法的不同影响。）
静态/动态分支预测：第一次遇到条件分支时，微处理器使用静态分支预测，动态分支预测用于条件分支代码的后续执行。
参考文献：
答案 18 :(得分：110)
除了分支预测可能减慢你的速度之外，排序数组还有另一个优点：
您可以设置停止条件而不是仅检查值，这样您只需循环查看相关数据，然后忽略其余数据。
分支预测只会错过一次。
// sort backwards (higher values first), may be in some other part of the code
std::sort(data, data + arraySize, std::greater<int>());
for (unsigned c = 0; c < arraySize; ++c) {
if (data[c] < 128) {
break;
}
sum += data[c];
}
答案 19 :(得分：106)
在ARM上，不需要分支，因为每条指令都有一个4位条件字段，以零成本进行测试。这消除了对短分支的需要，并且不会出现分支预测。因此，由于排序的额外开销，排序版本将比ARM上的未排序版本运行得慢。内部循环看起来如下所示：
MOV R0, #0 // R0 = sum = 0
MOV R1, #0 // R1 = c = 0
ADR R2, data // R2 = addr of data array (put this instruction outside outer loop)
.inner_loop // Inner loop branch label
LDRB R3, [R2, R1] // R3 = data[c]
CMP R3, #128 // compare R3 to 128
ADDGE R0, R0, R3 // if R3 >= 128, then sum += data[c] -- no branch needed!
ADD R1, R1, #1 // c++
CMP R1, #arraySize // compare c to arraySize
BLT inner_loop // Branch to inner_loop if c < arraySize
答案 20 :(得分：96)
由于称为分支预测的现象，分类数组的处理速度比未分类数组快。
分支预测器是一个数字电路（在计算机体系结构中），试图预测分支的走向，从而改善指令流水线的流量。电路/计算机预测下一步并执行它。
做出错误的预测会导致返回上一步，并执行另一个预测。假设预测正确，代码将继续下一步。错误的预测会导致重复相同的步骤，直到发生正确的预测。
你的问题的答案非常简单。
在未排序的数组中，计算机会进行多次预测，从而导致错误发生的可能性增加。 然而，在排序数组中，计算机进行的预测较少，从而减少了出错的可能性。 做出更多预测需要更多时间。
Sorted Array：直道 ____________________________________________________________________________________ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
未排序数组：弯曲道路
______ ________
| |__|
分支预测：猜测/预测哪条道路是直的并且在没有检查的情况下跟随它
___________________________________________ Straight road
|_________________________________________|Longer road
虽然两条道路都到达同一目的地，但直道较短，另一条较长。如果那时你错误地选择了另一个，那么就没有回头了，所以如果你选择更长的路，你会浪费一些额外的时间。这类似于计算机中发生的情况，我希望这有助于您更好地理解。
另外，我想从评论中引用@Simon_Weaver：
它不会减少预测 - 它会减少不正确的预测。它仍然需要通过循环每次预测...
答案 21 :(得分：43)
避免分支预测错误的一种方法是建立查找表，并使用数据为其建立索引。 Stefan de Bruijn在回答中对此进行了讨论。
但是在这种情况下，我们知道值在[0，255]范围内，我们只关心值> =128。这意味着我们可以轻松地提取单个位来告诉我们是否需要值。 ：通过将数据右移7位，我们剩下的是0位或1位，我们只想在有1位的情况下将值相加。我们将此位称为“决策位”。
通过将决策位的0/1值用作数组的索引，无论数据是否排序，我们都可以使代码变得同样快。我们的代码将始终添加一个值，但是当决策位为0时，我们会将值添加到我们不在乎的位置。这是代码：
//测试
clock_t start = clock();
long long a[] = {0, 0};
long long sum;
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
int j = (data[c] >> 7);
a[j] += data[c];
}
}
double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
sum = a[1];
此代码浪费了一半的添加，但从未发生分支预测失败。对于随机数据，它比带有实际if语句的版本要快得多。
但是在我的测试中，显式查找表的速度比此表稍快，这可能是因为索引到查找表的速度比移位稍快。这显示了我的代码如何设置和使用查找表（在代码中，“ LookUp Table”意为“ lut”）。这是C ++代码：
//声明然后填写查询表
int lut[256];
for (unsigned c = 0; c < 256; ++c)
lut[c] = (c >= 128) ? c : 0;
// Use the lookup table after it is built
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
sum += lut[data[c]];
}
}
在这种情况下，查找表只有256个字节，因此非常适合高速缓存，并且速度很快。如果数据是24位值，而我们只想要其中的一半，则此技术将无法很好地工作...查找表太大而无法实用。另一方面，我们可以结合上面显示的两种技术：首先将这些位移开，然后对查找表进行索引。对于只需要上半部分值的24位值，我们可能会将数据右移12位，并为表索引保留12位的值。一个12位的表索引意味着一个4096个值的表，这可能是实际的。
索引数组而不是使用if语句的技术可用于确定要使用的指针。我看到了一个实现二叉树的库，它没有两个命名的指针（pLeft和pRight或其他），而是一个长度为2的指针数组，并使用“决策位”技术来决定遵循哪个。例如，代替：
if (x < node->value)
node = node->pLeft;
else
node = node->pRight;
this library would do something like:
i = (x < node->value);
node = node->link[i];
这是一个很好的解决方案，也许会奏效。
答案 22 :(得分：19)
Bjarne Stroustrup's Answer到这个问题：
这听起来像一个面试问题。是真的吗你怎么知道的？在不先进行测量的情况下回答有关效率的问题是一个坏主意，因此了解如何进行测量很重要。
因此，我尝试使用一百万个整数的向量并得到：
Already sorted 32995 milliseconds
Shuffled 125944 milliseconds
Already sorted 18610 milliseconds
Shuffled 133304 milliseconds
Already sorted 17942 milliseconds
Shuffled 107858 milliseconds
我跑了几次来确定。是的，这种现象是真实的。我的关键代码是：
void run(vector<int>& v, const string& label)
{
auto t0 = system_clock::now();
sort(v.begin(), v.end());
auto t1 = system_clock::now();
cout << label
<< duration_cast<microseconds>(t1 — t0).count()
<< " milliseconds\n";
}
void tst()
{
vector<int> v(1'000'000);
iota(v.begin(), v.end(), 0);
run(v, "already sorted ");
std::shuffle(v.begin(), v.end(), std::mt19937{ std::random_device{}() });
run(v, "shuffled ");
}
至少对于这种编译器，标准库和优化器设置来说，这种现象是真实的。不同的实现可以而且确实给出不同的答案。实际上，有人确实做了更系统的研究（可以通过快速的网络搜索找到它），并且大多数实现都显示出这种效果。
一个原因是分支预测：排序算法中的关键操作是“if(v[i] < pivot]) …”或等效操作。对于排序序列，测试始终为真，而对于随机序列，选择的分支随机变化。
另一个原因是，当向量已经排序时，我们不需要将元素移到正确的位置。这些小细节的影响是我们看到的五六个因素。
Quicksort（通常是排序）是一项复杂的研究，吸引了计算机科学的一些最伟大的头脑。好的排序功能是选择好的算法并在实现过程中注意硬件性能的结果。
如果要编写高效的代码，则需要对机器体系结构有所了解。
答案 23 :(得分：17)
由其他答案得出的关于人们需要对数据进行排序的假设是不正确的。
以下代码不会对整个数组进行排序，而是仅对其200个元素的段进行排序，因此运行速度最快。
仅排序k个元素部分将以线性时间而不是imResampleMex完成预处理。
n.log(n)这也“证明”它与任何算法问题（例如排序顺序）无关，并且确实是分支预测。
答案 24 :(得分：12)
此问题源于CPU上的分支预测模型。我建议阅读本文：
Increasing the Instruction Fetch Rate via Multiple Branch Prediction and a Branch Address Cache
对元素进行排序后，IR不会一次又一次地获取所有CPU指令，而是从缓存中获取它们。
答案 25 :(得分：9)
这称为分支预测。如果没有分支预测，处理器将不得不等到条件跳转指令通过执行阶段，然后下一条指令才能进入流水线中的提取阶段。分支预测器试图通过尝试猜测是否最有可能采用或不采用条件跳转来避免这种时间浪费。然后被猜测为最可能的分支被提取并推测性地执行。如果稍后检测到猜测错误，则推测性地执行，导致延迟。
data[c] >= 128
从此链接获得更多帮助：Multiple Branch Prediction for Wide-Issue Superscalar
答案 26 :(得分：2)
也许你不应该对数据进行排序，因为输出值范围是有限的。计算每个值发生的次数要快得多。
例如您在 0..3 之间有 20 个数据，那么您可以保留 3 个计数器。最后你可能有： { 0: 10x , 1: 8x, 2: 2x }
将此数组转换回线性数组很容易，只需打印 10x 0、8x 1、2x 2。
当数值不是 0..2 但仍然有限时，您仍然可以考虑这种方法。排序总是很慢！ 其他优点：代码量小，易于阅读和测试，错误较少。
- 我写了这段代码，但我无法理解我的错误
- 我无法从一个代码实例的列表中删除 None 值，但我可以在另一个实例中。为什么它适用于一个细分市场而不适用于另一个细分市场？
- 是否有可能使 loadstring 不可能等于打印？卢阿
- java中的random.expovariate()
- Appscript 通过会议在 Google 日历中发送电子邮件和创建活动
- 为什么我的 Onclick 箭头功能在 React 中不起作用？
- 在此代码中是否有使用“this”的替代方法？
- 在 SQL Server 和 PostgreSQL 上查询，我如何从第一个表获得第二个表的可视化
- 每千个数字得到
- 更新了城市边界 KML 文件的来源？