我的直接猜测是第二个更快，不是因为对循环所做的更改，而是因为它是第二个，所以该高速缓存在运行时已经准备好了。
为了测试这个理论，我重新排列了你的代码，以颠倒调用这两个计算的顺序：

#include <cstdint>
#include <chrono>
#include <cstdio>

using std::uint64_t;

uint64_t superCalculationA(int init, int end)
{
    uint64_t total = 0;
    for (int i = init; i < end; i++)
        total += i;
    return total;
}

uint64_t superCalculationB(int init, int todo)
{
    uint64_t total = 0;
    for (int i = init; i < init + todo; i++)
        total += i;
    return total;
}

int main()
{
    const uint64_t answer = 500000110500000000;

    std::chrono::time_point<std::chrono::high_resolution_clock> start, end;
    double elapsed;

    std::printf("=====================================================\n");

    start = std::chrono::high_resolution_clock::now();
    uint64_t ret2 = superCalculationB(111, 1000000000);
    end = std::chrono::high_resolution_clock::now();
    elapsed = (end - start).count() * ((double) std::chrono::high_resolution_clock::period::num / std::chrono::high_resolution_clock::period::den);
    std::printf("Elapsed time: %.3f s | %.3f ms | %.3f us\n", elapsed, 1e+3*elapsed, 1e+6*elapsed);

    start = std::chrono::high_resolution_clock::now();
    uint64_t ret1 = superCalculationA(111, 1000000111);
    end = std::chrono::high_resolution_clock::now();
    elapsed = (end - start).count() * ((double) std::chrono::high_resolution_clock::period::num / std::chrono::high_resolution_clock::period::den);
    std::printf("Elapsed time: %.3f s | %.3f ms | %.3f us\n", elapsed, 1e+3*elapsed, 1e+6*elapsed);

    if (ret1 == answer)
    {
        std::printf("The first method, i.e. superCalculationA, succeeded.\n");
    }
    if (ret2 == answer)
    {
        std::printf("The second method, i.e. superCalculationB, succeeded.\n");
    }

    std::printf("=====================================================\n");

    return 0;
}

字符串
我得到的结果是：

=====================================================
Elapsed time: 0.286 s | 286.000 ms | 286000.000 us
Elapsed time: 0.271 s | 271.000 ms | 271000.000 us
The first method, i.e. superCalculationA, succeeded.
The second method, i.e. superCalculationB, succeeded.
=====================================================

型
所以，当版本A首先运行时，它会慢一些。当版本B首先运行时，它会慢一些。
为了确认，我在对版本A或版本B进行计时之前，添加了一个对superCalculationB的额外调用。之后，我尝试运行程序三次。对于这三次运行，我认为结果是平局（版本A快一次，版本B快两次，但既没有赢得依赖性，也没有获得足够大的优势，没有意义）。
这并不能证明这实际上是一种缓存情况，但给予一个相当强的指示，即这是函数调用顺序的问题，而不是代码本身的差异。
至于编译器为了使代码更快而做的事情：它做的主要事情是展开循环的几次迭代。如果我们手工展开几次迭代，我们可以得到几乎相同的效果：

uint64_t superCalculationC(int init, int end)
{
    int f_end = end - ((end - init) & 7);

    int i;
    uint64_t total = 0;
    for (i = init; i < f_end; i += 8) {
        total += i;
        total += i + 1;
        total += i + 2;
        total += i + 3;
        total += i + 4;
        total += i + 5;
        total += i + 6;
        total += i + 7;
    }

    for (; i < end; i++)
        total += i;

    return total;
}

型
这有一个属性，有些人可能会觉得很奇怪：实际上用-O2编译比用-O3编译快。用-O2编译时，它也比用-O3编译的其他两个快五倍。
与编译器的循环展开相比，速度提高了约5倍的主要原因是我们展开了与编译器不同的循环（更智能，IMO）。我们计算f_end来告诉我们展开的循环应该执行多少次。我们执行这些迭代，* 然后 * 我们执行一个单独的循环来“清理”结束时的任何奇数迭代。
相反，编译器生成的代码大致相当于这样的代码：

for (i = init; i < end; i += 8) {
    total += i;
    if (i + 1 >= end) break;
    total += i + 1;
    if (i + 2 >= end) break;
    total += i + 2;
    // ...
}

型
虽然这比循环根本没有展开时快得多，但从主循环中消除这些额外的检查并为任何奇数迭代执行单独的循环仍然快得多。
考虑到这样一个微不足道的循环体被执行了如此多的次数，你还可以通过展开更多的循环迭代来进一步提高速度（当使用-O2编译时）。展开16次迭代时，它的速度大约是上面代码展开8次迭代时的两倍：

uint64_t superCalculationC(int init, int end)
{
    int first_end = end - ((end - init) & 0xf);

    int i;
    uint64_t total = 0;
    for (i = init; i < first_end; i += 16) {
        total += i + 0;
        total += i + 1;
        total += i + 2;

        // code for `i+3` through `i+13` goes here

        total += i + 14;
        total += i + 15;
    }

    for (; i < end; i++)
        total += i;

    return total;
}

型
我还没有尝试探索展开这个特定循环的增益极限，但是展开32次迭代几乎使速度再次翻倍。根据您使用的处理器，您可能会通过展开64次迭代获得一些小的增益，但我猜我们开始接近极限-在某个时候，性能增益可能会趋于平稳，然后（如果你展开更多的迭代）可能会下降，很可能是戏剧性的。
总结：使用-O3，编译器展开循环的多次迭代。在这种情况下，这是非常有效的，主要是因为我们有 * 许多 * 几乎最琐碎的循环体的执行。手动展开循环甚至比让编译器做它更有效-我们可以更智能地展开，我们可以简单地展开比编译器更多的迭代。额外的智能可以给予我们大约5：1的改进，额外的迭代可以再增加4：1左右（代价是代码更长，可读性稍差）。
最后警告：和优化一样，你的收益可能会有所不同。编译器和/或处理器的差异意味着你可能会得到至少与我不同的结果。我希望我的手展开循环在大多数情况下比其他两个快得多，但具体快多少可能会有所不同。
1.但请注意，这是将使用-O2的手动展开循环与使用-O3的原始循环进行比较。当使用-O3编译时，手动展开循环运行得慢得多。

检查程序集输出实际上是阐明这些问题的唯一方法。
更好的优化将做很多事情，包括不严格“符合标准”的事情（尽管，据我所知，-O1和-O2不是这种情况）-例如检查，-Ofast开关。
我发现这很有帮助：http://gcc.godbolt.org/，并且使用演示代码here

-氧气

解释-O2结果很容易，查看从godbolt更改为-O2的代码

main:
pushq   %rbx
movl    $.LC2, %edi
call    puts
call    std::chrono::_V2::system_clock::now()
movq    %rax, %rbx
call    std::chrono::_V2::system_clock::now()
pxor    %xmm0, %xmm0
subq    %rbx, %rax
movsd   .LC4(%rip), %xmm2
movl    $.LC6, %edi
movsd   .LC5(%rip), %xmm1
cvtsi2sdq   %rax, %xmm0
movl    $3, %eax
mulsd   .LC3(%rip), %xmm0
mulsd   %xmm0, %xmm2
mulsd   %xmm0, %xmm1
call    printf
call    std::chrono::_V2::system_clock::now()
movq    %rax, %rbx
call    std::chrono::_V2::system_clock::now()
pxor    %xmm0, %xmm0
subq    %rbx, %rax
movsd   .LC4(%rip), %xmm2
movl    $.LC6, %edi
movsd   .LC5(%rip), %xmm1
cvtsi2sdq   %rax, %xmm0
movl    $3, %eax
mulsd   .LC3(%rip), %xmm0
mulsd   %xmm0, %xmm2
mulsd   %xmm0, %xmm1
call    printf
movl    $.LC7, %edi
call    puts
movl    $.LC8, %edi
call    puts
movl    $.LC2, %edi
call    puts
xorl    %eax, %eax
popq    %rbx
ret

字符串
没有调用这两个函数，也没有比较结果。
为什么会这样呢？这当然是优化的力量，程序太简单了。
首先应用内联的力量，之后编译器可以看到所有参数实际上都是文字值（111，1000000111，100000000，50000011050000000），因此是常量。
它发现init + todo是一个循环不变量，并将它们替换为end，将end定义为end = init + todo = 111 + 1000000000 = 1000000111
现在我们知道这两个循环都只包含编译时的值。它们完全相同：

uint64_t total = 0;
for (int i = 111; i < 1000000111; i++)
    total += i;
return total;

型
编译器认为它是一个求和，total是累加器，它是一个等步长的求和，所以编译器使最终的循环展开，即all，但它知道这种形式的求和是
重写高斯公式s=n*（n+1）

111+1000000110
110+1000000109
...
1000000109+110
1000000110+111=1000000221

型
循环= 1000000111-111 = 1 E9
一半，因为我们得到了寻找的两倍
1000000221 * 1E9 / 2 = 50000011050000000
也就是查找50000011050000000的结果
现在它有了一个编译时常量的结果，它可以将它与想要的结果进行比较，并注意它总是为true，因此它可以删除它。
记录的时间是您PC上system_clock的最短时间。

-O0

• O 0的计时比较困难，很可能是函数和跳转缺少对齐的结果，µops缓存和loopbuffer都喜欢32字节的对齐。

asm("nop");

型
在A的循环前面，2-3可能会起作用。存储转发也喜欢它们的值自然对齐。

编辑：在了解了更多关于处理器流水线中的依赖关系之后，我修改了我的答案，删除了一些不必要的细节，并提供了一个更具体的解释。
看来-O 0情况下的性能差异是由于处理器流水线。
首先，汇编（用于-O 0构建），从Nemo的答案复制，并内联了一些我自己的注解：

superCalculationA(int, int):
    pushq   %rbp
    movq    %rsp, %rbp
    movl    %edi, -20(%rbp)    # init
    movl    %esi, -24(%rbp)    # end
    movq    $0, -8(%rbp)       # total = 0
    movl    -20(%rbp), %eax    # copy init to register rax
    movl    %eax, -12(%rbp)    # i = [rax]
    jmp .L7
.L8:
    movl    -12(%rbp), %eax    # copy i to register rax
    cltq
    addq    %rax, -8(%rbp)     # total += [rax]
    addl    $1, -12(%rbp)      # i++
.L7:
    movl    -12(%rbp), %eax    # copy i to register rax
    cmpl    -24(%rbp), %eax    # [rax] < end
    jl  .L8
    movq    -8(%rbp), %rax
    popq    %rbp
    ret

superCalculationB(int, int):
    pushq   %rbp
    movq    %rsp, %rbp
    movl    %edi, -20(%rbp)    # init
    movl    %esi, -24(%rbp)    # todo
    movq    $0, -8(%rbp)       # total = 0
    movl    -20(%rbp), %eax    # copy init to register rax
    movl    %eax, -12(%rbp)    # i = [rax]
    jmp .L11
.L12:
    movl    -12(%rbp), %eax    # copy i to register rax
    cltq
    addq    %rax, -8(%rbp)     # total += [rax]
    addl    $1, -12(%rbp)      # i++
.L11:
    movl    -20(%rbp), %edx    # copy init to register rdx
    movl    -24(%rbp), %eax    # copy todo to register rax
    addl    %edx, %eax         # [rax] += [rdx]  (so [rax] = init+todo)
    cmpl    -12(%rbp), %eax    # i < [rax]
    jg  .L12
    movq    -8(%rbp), %rax
    popq    %rbp
    ret

字符串
在这两个函数中，堆栈布局看起来像这样：

Addr Content

24   end/todo
20   init
16   <empty>
12   i
08   total
04   
00   <base pointer>

型
(Note total是一个64位整数，因此占用了两个4字节的插槽。）
以下是superCalculationA()的关键行：

addl    $1, -12(%rbp)      # i++
.L7:
    movl    -12(%rbp), %eax    # copy i to register rax
    cmpl    -24(%rbp), %eax    # [rax] < end

型
堆栈地址-12(%rbp)（保存i的值）在addl指令中写入，然后在下一条指令中立即读取。读指令在写入完成之前不能开始。这表示流水线中的块，导致superCalculationA()比superCalculationB()慢。
你可能会好奇为什么superCalculationB()没有这个相同的流水线块。它实际上只是gcc如何在-O 0中编译代码的一个工件，并不代表任何有趣的东西。基本上，在superCalculationA()中，比较i<end是通过从寄存器阅读i来执行的，而在superCalculationB()中，通过从堆栈阅读i来执行比较i<init+todo。
为了证明这只是一个人工制品，让我们替换

for (int i = init; i < end; i++)

型
与

for (int i = init; end > i; i++)

型
然后生成的程序集看起来是一样的，只是对键行做了以下更改：

addl    $1, -12(%rbp)      # i++
.L7:
    movl    -24(%rbp), %eax    # copy end to register rax
    cmpl    -12(%rbp), %eax    # i < [rax]

型
现在i从堆栈中读取，管道块消失了。下面是进行此更改后的性能数据：

=====================================================
Elapsed time: 2.296 s | 2295.812 ms | 2295812.000 us
Elapsed time: 2.368 s | 2367.634 ms | 2367634.000 us
The first method, i.e. superCalculationA, succeeded.
The second method, i.e. superCalculationB, succeeded.
=====================================================

型
应该注意的是，这实际上是一个玩具示例，因为我们使用-O 0进行编译。在现实世界中，我们使用-O2或-O3进行编译。在这种情况下，编译器以最小化流水线块的方式对指令进行排序，我们不需要担心是否要写i<end或end>i。

(This并不完全是一个答案，但它确实包含了更多的数据，包括一些与Jerry Coffin相冲突的数据。
有趣的问题是，为什么未优化的例程执行起来如此不同和违反直觉。-O2和-O3的情况相对容易解释，其他人也这样做了。
为了完整起见，here is the assembly（感谢@Rutan Kax）用于GCC 4.9.1生成的superCalculationA和superCalculationB：

superCalculationA(int, int):
    pushq   %rbp
    movq    %rsp, %rbp
    movl    %edi, -20(%rbp)
    movl    %esi, -24(%rbp)
    movq    $0, -8(%rbp)
    movl    -20(%rbp), %eax
    movl    %eax, -12(%rbp)
    jmp .L7
.L8:
    movl    -12(%rbp), %eax
    cltq
    addq    %rax, -8(%rbp)
    addl    $1, -12(%rbp)
.L7:
    movl    -12(%rbp), %eax
    cmpl    -24(%rbp), %eax
    jl  .L8
    movq    -8(%rbp), %rax
    popq    %rbp
    ret

superCalculationB(int, int):
    pushq   %rbp
    movq    %rsp, %rbp
    movl    %edi, -20(%rbp)
    movl    %esi, -24(%rbp)
    movq    $0, -8(%rbp)
    movl    -20(%rbp), %eax
    movl    %eax, -12(%rbp)
    jmp .L11
.L12:
    movl    -12(%rbp), %eax
    cltq
    addq    %rax, -8(%rbp)
    addl    $1, -12(%rbp)
.L11:
    movl    -20(%rbp), %edx
    movl    -24(%rbp), %eax
    addl    %edx, %eax
    cmpl    -12(%rbp), %eax
    jg  .L12
    movq    -8(%rbp), %rax
    popq    %rbp
    ret

字符串
在我看来，B确实做了更多的工作。
我的测试平台是运行Red Hat Enterprise 6 Update 3的2.9GHz桑迪桥EP处理器（E5-2690）。我的编译器是GCC 4.9.1，并生成上面的程序集。
为了确保Turbo Boost和相关的CPU频率欺骗技术不会干扰测量，我运行了：

pkill cpuspeed # if you have it running
grep MHz /proc/cpuinfo # to see where you start
modprobe acpi_cpufreq # if you do not have it loaded
cd /sys/devices/system/cpu 
for cpuN in cpu[0-9]* ; do
    echo userspace > $cpuN/cpufreq/scaling_governor
    echo 2000000 > $cpuN/cpufreq/scaling_setspeed
done
grep MHz /proc/cpuinfo # to see if it worked

型
这将CPU频率固定到2.0 GHz并禁用Turbo Boost。
Jerry观察到这两个例程运行得更快或更慢，这取决于他执行它们的顺序。* 我无法重现这个结果。* 对我来说，superCalculationB始终比superCalculationA快25-30%，无论Turbo Boost或时钟速度设置如何。这包括以任意顺序多次运行它们。例如，在2.0GHz时，superCalculationA始终需要4500 ms多一点，superCalculationB始终需要3600 ms以下一点。
我还没有看到任何理论，甚至开始解释这一点。

处理器很复杂。执行时间取决于许多因素，其中许多因素超出了您的控制范围。仅列出几种可能性：

a.您的计算机可能没有恒定的时钟速度。这可能是因为时钟速度通常设置得相当低，以避免浪费能源/电池寿命/产生过多的热量。当您的程序开始运行时，操作系统会计算出需要电源并增加时钟速度。为了验证，请更改调用的顺序-如果执行的第二个循环总是比第一个快，这可能是原因。
B.确切的执行速度，特别是对于像你这样的紧循环，取决于指令在内存中的对齐方式。如果它完全包含在一个缓存行而不是两个缓存行中，或者在两个缓存行而不是三个缓存行中，一些处理器可能会运行得更快。一些编译器会添加nop指令来对齐缓存行上的循环以优化这一点，很可能其中一个循环纯粹是运气好，因此跑得更快。
c.确切的执行速度可能取决于指令被分派的确切顺序。由于代码中的细微差异，稍微不同的代码可能以不同的速度运行，这可能是处理器相关的，并且无论如何编译器可能很难考虑。
d.有证据表明，英特尔处理器可能存在人工短循环的问题，这可能只发生在人工基准测试中。您的代码非常接近“人工”。在其他线程中讨论过非常短的循环运行速度意外缓慢的情况，添加指令可以使它们运行得更快。

对第一个问题的答复：
1.它做一次for循环后更快，但我不确定只是根据我的实验结果进行评论。（实验1更改它们的名称（B->A，A->B）实验2在时间检查前运行一个函数有for循环，实验3在时间检查前启动一个for循环）
1.第一个程序应该工作得更快，原因是第二个功能是当第一个功能做1个操作时做2个操作。
我在这里留下更新的代码来解释我的答案。
回答第二个问题：
我不确定，但我想到了两种方法，
它可以以某种方式形式化你的函数，并摆脱循环，因为这种方式可以消除差异（比如“return end-init”或“return todo”我不知道，我不确定）
它有-fauto_inc_dec，它可以产生这种差异，因为这些函数都是关于增量和减量的。
希望能帮上忙。

#include <cstdint>
#include <ctime>
#include <cstdio>

using std::uint64_t;

uint64_t superCalculationA(int init, int end)
{
    uint64_t total = 0;
    for (int i = init; i < end; i++)
        total += i;
    return total;
}
uint64_t superCalculationB(int init, int todo)
{
    uint64_t total = 0;
    for (int i = init; i < init+todo; i++)
        total += i;
    return total;
}
int add(int a1,int a2){printf("multiple times added\n");return a1+a2;}
uint64_t superCalculationC(int init, int todo)
{
    uint64_t total = 0;
    for (int i = init; i < add(init , todo); i++)
        total += i;
    return total;
}

int main()
{
    const uint64_t answer = 500000110500000000;

    std::clock_t start=clock();
    double elapsed;

    std::printf("=====================================================\n");

    superCalculationA(111, 1000000111);

    start = clock();
    uint64_t ret1 = superCalculationA(111, 1000000111);
    elapsed = ((std::clock()-start)*1.0/CLOCKS_PER_SEC);
    std::printf("Elapsed time: %.3f s | %.3f ms | %.3f us\n", elapsed, 1e+3*elapsed,    1e+6*elapsed);

    start = clock();
    uint64_t ret2 = superCalculationB(111, 1000000000);
    elapsed = ((std::clock()-start)*1.0/CLOCKS_PER_SEC);
    std::printf("Elapsed time: %.3f s | %.3f ms | %.3f us\n", elapsed, 1e+3*elapsed, 1e+6*elapsed);

    if (ret1 == answer)
    {
        std::printf("The first method, i.e. superCalculationA, succeeded.\n");
    }
    if (ret2 == answer)
    {
        std::printf("The second method, i.e. superCalculationB, succeeded.\n");
    }

    std::printf("=====================================================\n");

    return 0;
}

字符串