好的，正确的答案肯定要对CPU缓存做一些事情。但是使用缓存参数可能非常困难，尤其是没有数据。

有许多答案，导致了很多讨论，但让我们面对现实：缓存问题可能非常复杂，并不是一维的。它们在很大程度上取决于数据的大小，所以我的问题是不公平的：事实证明它在缓存图中非常有趣。

@Mysticial的回答让很多人（包括我）相信，可能是因为它是唯一一个似乎依赖于事实的人，但它只是事实的一个“数据点”。

这就是为什么我结合他的测试（使用连续分配和单独分配）和@James答案的建议。

下图显示，根据所使用的确切方案和参数，大多数答案，特别是对问题和答案的大多数评论可以被认为是完全错误或真实的。

请注意，我最初的问题是在 n = 100.000。这一点（偶然）表现出特殊的行为：

1. 它在一个和两个循环版本之间存在最大的差异（几乎是三分之一）

2. 这是唯一的一点，其中一个循环（即连续分配）胜过双循环版本。 （这使得Mysticial的答案成为可能。）

使用初始化数据的结果：

使用未初始化数据的结果（这是Mysticial测试的）：

这是一个难以解释的问题：初始化数据，分配一次并重复用于以下每个不同矢量大小的测试用例：

提案

应该要求Stack Overflow上的每个低级性能相关问题为整个缓存相关数据大小提供MFLOPS信息！浪费每个人的时间来思考答案，特别是在没有这些信息的情况下与他人讨论答案。

第二个循环涉及更少的缓存活动，因此处理器更容易满足内存需求。

想象一下，你正在一台机器上工作 n 它只是一个合适的值，它可以同时在内存中保存两个阵列，但是通过磁盘缓存可用的总内存仍足以容纳所有四个阵列。

假设一个简单的LIFO缓存策略，这段代码：

for(int j=0;j<n;j++){
    a[j] += b[j];
}
for(int j=0;j<n;j++){
    c[j] += d[j];
}

首先会导致 a 和 b 加载到RAM然后完全在RAM中工作。当第二个循环开始时， c 和 d 然后将从磁盘加载到RAM中并进行操作。

另一个循环

for(int j=0;j<n;j++){
    a[j] += b[j];
    c[j] += d[j];
}

将在另外两个中分页出两个数组和页面 每次循环。这显然是 许多 比较慢。

您可能没有在测试中看到磁盘缓存，但您可能会看到其他形式的缓存的副作用。

这里似乎有一点混乱/误解，所以我将尝试用一个例子来详细说明。

说 n = 2 我们正在使用字节。因此，在我的情景中，我们有 只有4个字节的缓存 而其余的记忆速度明显较慢（比如说访问时间长100倍）。

假设一个相当愚蠢的缓存策略 如果该字节不在缓存中，那么将它放在那里并在我们处理时得到以下字节 你会得到一个像这样的场景：

• 同

  for(int j=0;j<n;j++){
   a[j] += b[j];
  }
  for(int j=0;j<n;j++){
   c[j] += d[j];
  }
  

• 高速缓存 a[0] 和 a[1] 然后 b[0] 和 b[1] 并设置 a[0] = a[0] + b[0] 在缓存中 - 缓存中现在有四个字节， a[0], a[1] 和 b[0], b[1]。成本= 100 + 100。

• 组 a[1] = a[1] + b[1] 在缓存中。成本= 1 + 1。
• 重复一遍 c 和 d。

• 总费用= (100 + 100 + 1 + 1) * 2 = 404

• 同

  for(int j=0;j<n;j++){
   a[j] += b[j];
   c[j] += d[j];
  }
  

• 高速缓存 a[0] 和 a[1] 然后 b[0] 和 b[1] 并设置 a[0] = a[0] + b[0] 在缓存中 - 缓存中现在有四个字节， a[0], a[1] 和 b[0], b[1]。成本= 100 + 100。

• 喷射 a[0], a[1], b[0], b[1] 来自缓存和缓存 c[0] 和 c[1] 然后 d[0] 和 d[1] 并设置 c[0] = c[0] + d[0] 在缓存中。成本= 100 + 100。
• 我怀疑你开始明白我要去哪里了。
• 总费用= (100 + 100 + 100 + 100) * 2 = 800

这是一个经典的缓存捶打场景。

这不是因为代码不同，而是因为缓存：RAM比CPU寄存器慢，CPU内部有缓存，以避免每次变量更改时写入RAM。但是缓存并不像RAM那么大，因此，它只映射了一小部分。

第一个代码修改在每个循环中交替它们的远程存储器地址，因此需要连续地使高速缓存无效。

第二个代码不会交替：它只是在相邻地址上流动两次。这使得所有作业都在缓存中完成，仅在第二个循环开始后使其无效。

我不能复制这里讨论的结果。

我不知道糟糕的基准代码是否应该受到责备，或者是什么，但是这两种方法在我的机器上使用下面的代码在10％之内，并且一个循环通常只比两个快一点 - 就像你一样期望。

阵列大小范围从2 ^ 16到2 ^ 24，使用八个循环。我小心地初始化源数组，所以 += 任务没有问 FPU 添加内存垃圾解释为double。

我玩各种方案，比如把作业分配给 b[j]， d[j] 至 InitToZero[j] 在循环内部，以及使用 += b[j] = 1 和 += d[j] = 1，我得到了相当一致的结果。

正如您所料，初始化 b 和 d 在循环内使用 InitToZero[j] 使得组合方法具有优势，因为它们在分配之前背靠背地完成 a 和 c，但仍在10％以内。去搞清楚。

硬件是 戴尔XPS 8500 与第3代 酷睿i7 @ 3.4 GHz和8 GB内存。对于2 ^ 16到2 ^ 24，使用八个循环，累积时间分别为44.987和40.965。 Visual C ++ 2010，完全优化。

PS：我改变了循环以倒数到零，并且组合方法稍微快一点。抓我的头。请注意新的数组大小和循环计数。

// MemBufferMystery.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include <cmath>
#include <string>
#include <time.h>

#define  dbl    double
#define  MAX_ARRAY_SZ    262145    //16777216    // AKA (2^24)
#define  STEP_SZ           1024    //   65536    // AKA (2^16)

int _tmain(int argc, _TCHAR* argv[]) {
    long i, j, ArraySz = 0,  LoopKnt = 1024;
    time_t start, Cumulative_Combined = 0, Cumulative_Separate = 0;
    dbl *a = NULL, *b = NULL, *c = NULL, *d = NULL, *InitToOnes = NULL;

    a = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    b = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    c = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    d = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    InitToOnes = (dbl *)calloc( MAX_ARRAY_SZ, sizeof(dbl));
    // Initialize array to 1.0 second.
    for(j = 0; j< MAX_ARRAY_SZ; j++) {
        InitToOnes[j] = 1.0;
    }

    // Increase size of arrays and time
    for(ArraySz = STEP_SZ; ArraySz<MAX_ARRAY_SZ; ArraySz += STEP_SZ) {
        a = (dbl *)realloc(a, ArraySz * sizeof(dbl));
        b = (dbl *)realloc(b, ArraySz * sizeof(dbl));
        c = (dbl *)realloc(c, ArraySz * sizeof(dbl));
        d = (dbl *)realloc(d, ArraySz * sizeof(dbl));
        // Outside the timing loop, initialize
        // b and d arrays to 1.0 sec for consistent += performance.
        memcpy((void *)b, (void *)InitToOnes, ArraySz * sizeof(dbl));
        memcpy((void *)d, (void *)InitToOnes, ArraySz * sizeof(dbl));

        start = clock();
        for(i = LoopKnt; i; i--) {
            for(j = ArraySz; j; j--) {
                a[j] += b[j];
                c[j] += d[j];
            }
        }
        Cumulative_Combined += (clock()-start);
        printf("\n %6i miliseconds for combined array sizes %i and %i loops",
                (int)(clock()-start), ArraySz, LoopKnt);
        start = clock();
        for(i = LoopKnt; i; i--) {
            for(j = ArraySz; j; j--) {
                a[j] += b[j];
            }
            for(j = ArraySz; j; j--) {
                c[j] += d[j];
            }
        }
        Cumulative_Separate += (clock()-start);
        printf("\n %6i miliseconds for separate array sizes %i and %i loops \n",
                (int)(clock()-start), ArraySz, LoopKnt);
    }
    printf("\n Cumulative combined array processing took %10.3f seconds",
            (dbl)(Cumulative_Combined/(dbl)CLOCKS_PER_SEC));
    printf("\n Cumulative seperate array processing took %10.3f seconds",
        (dbl)(Cumulative_Separate/(dbl)CLOCKS_PER_SEC));
    getchar();

    free(a); free(b); free(c); free(d); free(InitToOnes);
    return 0;
}

我不确定为什么MFLOPS是一个相关指标。我的想法是关注内存访问，所以我试着最小化浮点计算时间。我离开了 +=，但我不确定为什么。

没有计算的直接分配将是对存储器访问时间的更清晰的测试，并且无论循环计数如何都将创建均匀的测试。也许我在谈话中遗漏了一些东西，但值得三思。如果加号未被分配，则累计时间几乎相同，每次31秒。

这是因为CPU没有那么多缓存未命中（必须等待阵列数据来自RAM芯片）。你可以有意识地不断调整阵列的大小，以便超过大小 1级缓存 （L1），然后是 二级缓存 （L2），你的CPU，并根据数组的大小绘制代码执行所需的时间。图表不应该像您期望的那样是直线。

第一个循环交替写入每个变量。第二个和第三个只是元素大小的小跳跃。

尝试用笔和纸隔开20厘米写两条平行的20个十字线。尝试完成一个然后另一个行，然后通过交替地在每一行中写一个十字来尝试另一次。

原始问题

为什么一个循环比两个循环慢得多？

评估问题

OP的代码：

const int n=100000;

for(int j=0;j<n;j++){
    a1[j] += b1[j];
    c1[j] += d1[j];
}

和

for(int j=0;j<n;j++){
    a1[j] += b1[j];
}
for(int j=0;j<n;j++){
    c1[j] += d1[j];
}

考虑

考虑OP关于for循环的两个变体的原始问题以及他对缓存行为的修正问题以及许多其他优秀答案和有用的评论;我想通过对这种情况和问题采取不同的方法来尝试做一些与众不同的事情。

该方法

考虑到两个循环以及关于缓存和页面归档的所有讨论，我想采用另一种方法来从不同的角度来看待这个问题。一个不涉及缓存和页面文件，也不涉及分配内存的执行，实际上这种方法甚至根本不涉及实际的硬件或软件。

透视

在查看代码一段时间之后，很明显问题是什么以及产生什么。让我们将其分解为一个算法问题，并从使用数学符号的角度来看待它，然后对数学问题和算法进行类比。

我们所知道的

我们知道他的循环将运行100,000次。我们也知道 a1， b1， c1 ＆ d1 是64位架构的指针。在32位机器上的C ++中，所有指针都是4个字节，而在64位机器上，它们的大小是8个字节，因为指针具有固定长度。我们知道在两种情况下我们都有32个字节可供分配。唯一的区别是我们在每次迭代时分配32个字节或2个2-8字节集合，在第二种情况下，我们为每个独立循环的每次迭代分配16个字节。因此，两个循环在总分配中仍然等于32个字节。有了这些信息，我们继续展示它的一般数学，算法和类比。我们知道在两种情况下必须执行相同集合或操作组的次数。我们知道在两种情况下都需要分配的内存量。我们可以评估两种情况之间分配的总体工作量大致相同。

我们不知道的

我们不知道每个案件需要多长时间，除非我们设置一个柜台并进行基准测试。然而，基准分数已经包含在原始问题和一些答案和评论中，我们可以看到两者之间存在显着差异，这就是这个问题对这个问题的整体推理以及对它的回答。首先。

我们来调查吧 

很明显，许多人已经通过查看堆分配，基准测试，查看RAM，缓存和页面文件来完成此操作。还包括了特定的数据点和特定的迭代索引，关于这个特定问题的各种对话让很多人开始质疑其他相关的事情。那么我们如何通过使用数学算法并对其进行类比来开始研究这个问题呢？我们首先做几个断言！然后我们从那里构建我们的算法。

我们的断言：

• 我们将让循环及其迭代成为一个从1开始并以100000结束而不是从循环开始的Summation，因为我们不需要担心内存寻址的0索引方案，因为我们只对它感兴趣算法本身。
• 在这两种情况下，我们有4个函数可以使用，2个函数调用，每个函数调用都有2个操作。所以我们将它们设置为函数和函数调用 F1()， F2()， f(a)， f(b)， f(c) 和 f(d)。

算法：

第一案例：  - 只有一个求和，但有两个独立的函数调用。

Sum n=1 : [1,100000] = F1(), F2();
                       F1() = { f(a) = f(a) + f(b); }
                       F2() = { f(c) = f(c) + f(d);  }

第二个案例：  - 两个求和但每个都有自己的函数调用。

Sum1 n=1 : [1,100000] = F1();
                        F1() = { f(a) = f(a) + f(b); }

Sum2 n=1 : [1,100000] = F1();
                        F1() = { f(c) = f(c) + f(d); }

如果你注意到了 F2() 只存在于 Sum 哪两个 Sum1 和 Sum2 只包含 F1()。当我们开始断定第二种算法发生了某种优化时，这也将在后面明显。

通过第一种情况的迭代 Sum 电话 f(a) 这会增加自我 f(b) 然后它打电话 f(c) 这将做同样但添加 f(d) 为每个人自己 100000 iterations。在第二种情况下，我们有 Sum1 和 Sum2 并且两者的行为相同，就好像它们是连续两次调用的相同函数一样。 在这种情况下，我们可以治疗 Sum1 和 Sum2 就像老了 Sum 哪里 Sum 在这种情况下看起来像这样： Sum n=1 : [1,100000] { f(a) = f(a) + f(b); } 现在这看起来像一个优化，我们可以认为它是相同的功能。

类比摘要

根据我们在第二种情况下看到的情况，它几乎看起来好像存在优化，因为两个for循环具有相同的精确签名，但这不是真正的问题。问题不在于正在进行的工作 f(a)，f(b)，f(c)＆f(d) 在两种情况下以及两者之间的比较中，Summation必须在两种情况下都行进的距离的差异给出了时间执行的差异。

想想 For Loops 作为 Summations 将迭代视为a Boss 这是给两个人的命令 A ＆ B 他们的工作就是吃肉 C ＆ D 分别从他们那里拿起一些包裹并归还。在这里类比，for循环或求和迭代和条件检查本身实际上并不代表 Boss。实际代表什么 Boss 这里不是直接来自实际的数学算法，而是来自实际的概念 Scope 和 Code Block 在例程或子例程，方法，函数，翻译单元等中。第一算法具有1个范围，其中第二算法具有2个连续范围。

在每个呼叫的第一个案例中滑动 Boss 去 A 并给出订单和 A 去取 B's 然后包 Boss 去 C 并给出相同的命令并从中接收包裹 D 在每次迭代。

在第二种情况下 Boss 直接使用 A 去取 B's 包装直到收到所有包裹。然后 Boss与...合作 C 为了获得所有这些而做同样的事情 D's 包。

由于我们正在使用8字节指针并处理堆分配，所以我们在这里考虑这个问题。让我们说一下 Boss 距离100英尺 A 然后 A 距离500英尺 C。我们不需要担心这有多远 Boss 最初来自 C 因为执行的顺序。在这两种情况下 Boss 最初来自 A 先到了 B。这个类比并不是说这个距离是准确的;它只是一个使用测试用例场景来显示算法的工作原理。在许多情况下，在进行堆分配并使用缓存和页面文件时，地址位置之间的这些距离在差异上可能不会有太大变化，或者它们可能非常显着地取决于数据类型的性质和数组大小。

测试用例：

第一例： 在第一次迭代时 Boss 最初需要100英尺才能完成订单 A 和 A 离开并做他的事，但然后 Boss 必须前往500英尺 C 给他他的订单单。然后在下一次迭代和之后的每次其他迭代 Boss 必须在两者之间来回500英尺。

第二种情况：  The Boss 必须在第一次迭代时行进100英尺 A，但之后他已经在那里等待了 A 回来直到所有单据都填满。然后 Boss 必须在第一次迭代时行进500英尺 C 因为 C 距离500英尺 A 从此 Boss( Summation, For Loop ) 在工作之后正在被召唤 A 然后就像他一样等待 A 直到全部 C's 订单单已完成。

旅行距离的差异

const n = 100000
distTraveledOfFirst = (100 + 500) + ((n-1)*(500 + 500); 
// Simplify
distTraveledOfFirst = 600 + (99999*100);
distTraveledOfFirst = 600 + 9999900;
distTraveledOfFirst =  10000500;
// Distance Traveled On First Algorithm = 10,000,500ft

distTraveledOfSecond = 100 + 500 = 600;
// Distance Traveled On Second Algorithm = 600ft;    

任意价值观的比较

我们可以很容易地看到600远远低于1000万。现在这不完全正确，因为我们不知道RAM的地址与每个迭代的每个调用的Cache或Page File之间的距离的实际差异是由于许多其他看不见的变量，但这只是评估从最坏情况下要注意并试图查看的情况。

因此，通过这些数字，几乎看起来算法一应该比算法二慢99％;然而，这只是 The Boss's 算法的一部分或责任，它不考虑实际的工人 A， B， C，＆ D 以及他们在循环的每次迭代中必须做什么。所以老板的工作只占工作总量的15-40％。因此，通过工人完成的大部分工作对将速度差异的比率保持在约50-70％有轻微的影响

观察：  - 两种算法之间的差异

在这种情况下，它是正在完成的工作过程的结构，它确实表明了这一点 案例2从具有类似函数声明和定义的部分优化两者来看，效率更高，其中只有名称不同的变量。而且我们也看到了旅行的总距离 情况1 远远超过它 案例2 我们可以认为这个距离是我们的 时间因素 两种算法之间。 情况1 还有很多工作要做 案例2 确实。这也是在证据中看到的 ASM 两个案例之间都显示出来。即使已经就这些案例所说的话，它也没有考虑到这一事实 情况1 老板将不得不等待两者 A ＆ C 在他回去之前回来 A 再次在下一次迭代中，它也没有考虑到if的事实 A 要么 B 两个人都花了很长时间 Boss 而其他工人也在等待闲置。在 案例2 唯一一个空闲的是 Boss 直到工人回来所以即使这对算法也有影响。

结论：

情况1 是一个经典的插值问题，恰好是一个效率低下的问题。我还认为这是为什么许多机器架构和开发人员最终构建和设计具有多线程应用程序以及并行编程能力的多核系统的主要原因之一。

因此，即使从这种方法看它，甚至不涉及硬件，操作系统和编译器如何协同工作以进行涉及使用RAM，缓存，页面文件等的堆分配;它背后的数学已经向我们展示了这两个中的哪一个是使用上述类比的更好的解决方案 Boss 或者 Summations 是那些 For Loops 必须在工人之间旅行 A ＆ B。我们很容易看出来 案例2 如果不是多一点，至少要快1/2 情况1 由于行进的距离和所花费的时间的差异。这个数学几乎完全符合Bench Mark Times以及装配指令数量的差异。

OPs修订问题

编辑：问题证明是无关紧要的，因为行为严重依赖于数组（n）和CPU缓存的大小。因此，如果有进一步的兴趣，我重新提出这个问题：

您能否提供一些有关导致不同缓存行为的详细信息，如下图中的五个区域所示？

通过为这些CPU提供类似的图表，指出CPU /缓存架构之间的差异也可能是有趣的。

关于这些问题

正如我毫无疑问地证明的那样，即使在涉及硬件和软件之前也存在潜在的问题。现在关于内存和缓存以及页面文件等的管理，它们在一组集成的系统中一起工作： The Architecture {硬件，固件，一些嵌入式驱动程序，内核和ASM指令集}， The OS{文件和内存管理系统，驱动程序和注册表}， The Compiler {源代码的翻译单位和优化}，甚至是 Source Code 本身就有一套独特的算法;我们已经可以看到，在我们将它应用于任意任意机器之前，在第一个算法中发生了瓶颈 Architecture， OS，和 Programmable Language与第二种算法相比。因此在涉及现代计算机的内在函数之前就已存在问题。

结局结果

然而;并不是说这些新问题不重要，因为它们本身就是，而且它们确实起了作用。它们确实会对程序和整体绩效产生影响，这一点可以从许多给出答案和/或评论的图表和评估中看出来。如果你注意的比喻 Boss 和两个工人 A ＆ B 谁必须去检索包裹 C ＆ D 分别考虑到两个算法的数学符号你可以看到甚至没有计算机的参与 Case 2 大约快60％ Case 1 当您将这些算法应用于源代码后查看图形和图表，通过操作系统进行编译和优化并执行以在给定硬件上执行操作时，您甚至会看到这些算法之间的差异稍微降低。

现在，如果“数据”集合相当小，那么起初可能看起来并不是那么糟糕但是从那以后 Case 1 是关于 60 - 70% 慢于 Case 2 我们可以将这个函数的增长看作是时间执行的差异：

DeltaTimeDifference approximately = Loop1(time) - Loop2(time)
//where 
Loop1(time) = Loop2(time) + (Loop2(time)*[0.6,0.7]) // approximately
// So when we substitute this back into the difference equation we end up with 
DeltaTimeDifference approximately = (Loop2(time) + (Loop2(time)*[0.6,0.7])) - Loop2(time)
// And finally we can simplify this to
DeltaTimeDifference approximately = [0.6,0.7]*(Loop2(time)

这个近似值是这两个循环在算法和机器操作之间的平均差异，涉及软件优化和机器指令。因此，当数据集线性增长时，两者之间的时间差也是如此。算法1具有比算法2更多的提取，这在算法2中是明显的 Boss 不得不往返于两者之间的最大距离 A ＆ C 对于第一次迭代后的每次迭代，同时算法2 Boss 不得不前往 A 完成之后一次又一次 A 他离开时只需要行驶一次最大距离 A 至 C。

所以试着拥有 Boss 专注于同时做两件类似的事情并且来回摆弄它们而不是专注于类似的连续任务会让他在一天结束时非常生气，因为他必须旅行和工作两倍。因此，让老板陷入内插瓶颈，因为老板的配偶和孩子不会欣赏它，因此不会失去这种情况的范围。

可能是旧的C ++和优化。在我的电脑里，我获得了几乎相同的速度：

一个循环：1.577ms 两个循环：1.507ms

我在带有16Gb内存的E5-1620 3.5Ghz处理器上运行VS2015