为什么在堆上迭代一个大数组比在堆栈上迭代相同大小的数组更快？答案

【问题标题】：Why is iterating a large array on the heap faster than iterating same size array on the stack?为什么在堆上迭代一个大数组比在堆栈上迭代相同大小的数组更快？
【发布时间】：2012-10-16 04:06:34
【问题描述】：

我正在分配 2 个相同大小的数组，一个在堆栈上，一个在堆上，然后通过简单的赋值对它们进行迭代。

可执行文件被编译为主线程堆栈分配 40mb。

此代码仅经过测试，可在带有 /STACK:41943040 链接器标记的 vc++ 中编译。

#include "stdafx.h"
#include <string>
#include <iostream>
#include <malloc.h>
#include <windows.h>
#include <ctime>

using namespace std;

size_t stackavail()
{
    static unsigned StackPtr;   // top of stack ptr
    __asm mov [StackPtr],esp    // mov pointer to top of stack
    static MEMORY_BASIC_INFORMATION mbi;            // page range
    VirtualQuery((PVOID)StackPtr,&mbi,sizeof(mbi)); // get range
    return StackPtr-(unsigned)mbi.AllocationBase;   // subtract from top (stack grows downward on win)
}

int _tmain(int argc, _TCHAR* argv[])
{
    string input;

    cout << "Allocating 22mb on stack." << endl;
    unsigned int start = clock();
    char eathalfastack[23068672]; // approx 22mb
    auto length = sizeof(eathalfastack)/sizeof(char);
    cout << "Time taken in ms: " << clock()-start << endl;

    cout << "Setting through array." << endl;
    start = clock();
    for( int i = 0; i < length; i++ ){
        eathalfastack[i] = i;
    }
    cout << "Time taken in ms: " << clock()-start << endl;
    cout << "Free stack space: " << stackavail() << endl;


    cout << "Allocating 22mb on heap." << endl;
    start = clock();
    // auto* heaparr = new int[23068672]; // corrected
    auto* heaparr = new byte[23068672];
    cout << "Time taken in ms: " << clock()-start << endl;

    start = clock();
    cout << "Setting through array." << endl;
    for( int i = 0; i < length; i++ ){
        heaparr[i] = i;
    }
    cout << "Time taken in ms: " << clock()-start << endl;

    delete[] heaparr;
    getline(cin, input);
}

输出是这样的：

    Allocating 22mb on stack.
    Time taken in ms: 0
    Setting through array.
    Time taken in ms: 45
    Free stack space: 18872076
    Allocating 22mb on heap.
    Time taken in ms: 20
    Setting through array.
    Time taken in ms: 35

为什么堆栈数组的迭代速度比堆上的相同？

编辑： nneonneo 吐出我的错误

现在输出是相同的：

    Allocating 22mb on stack.
    Time taken in ms: 0
    Setting through array.
    Time taken in ms: 42
    Free stack space: 18871952
    Allocating 22mb on heap.
    Time taken in ms: 4
    Setting through array.
    Time taken in ms: 41

根据 Öö Tiib 在下面的回答发布构建：

    Allocating 22mb on stack.
    Time taken in ms: 0
    Setting through array.
    Time taken in ms: 5
    Free stack space: 18873508
    Allocating 22mb on heap.
    Time taken in ms: 0
    Setting through array.
    Time taken in ms: 10

【问题讨论】：

因为堆栈在内存中更高，这意味着 CPU 需要进一步获取它:-) 不，只是在开玩笑。但是，您可能需要多次运行程序以获得更好的样本，并可能切换操作并重试。一个样本量是统计学家的噩梦。
@paxdiablo：这是我很久以来听到的最可怕的解释 X__X
是的，我不知道 pax 是在开玩笑还是我错过了问题中非常明显的东西。 :)
嗯，为什么有时使用std::cout 而其他时候使用cout？保持一致...
FWIW，我无法重现这些数字。堆的时间总是比堆栈的时间长——即使大小被校正为匹配。

标签： c++ visual-c++

【解决方案1】：

您的数组大小不同； sizeof(char[23068672]) != sizeof(int[23068672])，元素类型不同。

【讨论】：

但在堆的情况下会更大。然而堆还是更快？尽管时间仍然太小，无论如何都无法区分它们。
等等，还是得到类似的结果。
对堆栈上字符的未对齐访问也会减慢它的速度。

【解决方案2】：

你的电脑出了点问题，在我的旧 Pentium 4 上，分配这种基于堆栈的字符数组需要 15 毫秒。你试过调试版本还是什么的？

【讨论】：

这似乎是问题所在。现在是 5 毫秒与 10 毫秒。

【解决方案3】：

你的问题有两个部分：

在堆栈与堆上分配空间
访问堆栈上的内存位置与全局可见

分配空间

首先，让我们看看在堆栈上分配空间。我们所知道的堆栈在 x86 架构上向下增长。因此，为了在堆栈上分配空间，您所要做的就是减少堆栈指针。只有一条汇编指令（dec sp，#amount）。该汇编指令始终出现在函数的序言中（函数设置代码）。因此，据我所知，在堆栈上分配空间一定不会花费任何时间。在堆栈上分配空间的成本 = (递减 sp 操作)。在现代超标量机器上，该指令的执行将与其他指令重叠。

另一方面，在堆上分配空间需要对 new/malloc 的库调用。库调用首先检查堆上是否有空间。如果是，那么它将只返回一个指向第一个可用地址的指针。如果堆栈上没有可用空间，它将使用 brk 系统调用请求内核修改附加页的页表条目。系统调用是一项昂贵的操作。它会导致管道刷新，TLB污染等。因此，在堆上分配空间的成本=（函数调用+空间计算+（brk系统调用）？）。当然，在堆上分配空间似乎比堆栈慢一个数量级。

访问元素 x86 ISA 的寻址模式允许使用直接寻址模式 (temp=mem[addr]) 对内存操作数进行寻址以访问全局变量，而堆栈上的变量通常使用索引寻址模式访问。 (temp=mem[stack-pointer+offset-on-stack])。我的假设是两个内存操作数应该花费几乎相同的时间，但是，直接寻址模式似乎肯定比索引寻址模式快。关于数组的内存访问，我们有两个操作数可以访问任何元素——数组的基地址和索引变量。当我们访问堆栈上的数组时，我们添加了一个操作数 - 堆栈指针。 x86 寻址模式提供了此类地址 - base+scale*index+offset 。所以，好的堆栈数组元素访问：temp=mem[sp+base-address+iterator*element-size] 和堆数组访问：temp=mem[base-address+iterator*element-size]。显然，堆栈访问必须比数组访问更昂贵。

现在，来到一个通用的迭代案例，如果堆栈的迭代速度较慢，这意味着寻址模式可能（我不完全确定）瓶子-颈部，如果分配空间是瓶颈，系统调用可能是瓶颈。

【讨论】：