0

我正在编写一个需要大量堆内存的函数。是否可以告诉编译器这些数据将在特定for循环中被频繁访问,从而提高性能(通过编译选项或类似方法)?

我不能使用堆栈的原因是我需要存储的元素数量很大,如果我尝试这样做会出现分段错误。

现在代码正在运行,但我认为它可能会更快。

更新:我正在做这样的事情

vector< set<uint> > vec(node_vec.size());
for(uint i = 0; i < node_vec.size(); i++)
  for(uint j = i+1; j < node_vec.size(); j++)
    // some computation, basic math, store the result in variable x
      if( x > threshold ) {
         vec[i].insert(j);
         vec[j].insert(i);
      }

一些细节:
- 我使用了 hash_set,几乎没有改进,除了 hash_set 并非在我拥有的所有机器中都可用以用于模拟目的
- 我尝试使用数组在堆栈上分配 vec 但是,正如我所说,如果我可能会遇到分段错误元素数量太大

例如,如果 node_vec.size() 等于 k,其中 k 大约为几千,我希望 vec 比 node_vec 大 4 或 5 倍。考虑到我必须多次运行它,使用这个数量级的代码似乎很慢。当然,我使用多线程来并行化这些调用,但我不能让函数本身运行得比我现在看到的快得多。

例如,是否有可能在高速缓存内存中分配 vec 以进行快速数据检索,或类似的东西?

4

5 回答 5

3

我正在编写一个需要大量堆内存的函数......将在特定的 for 循环中频繁访问

这不是您可以在编译器级别真正优化的东西。我认为您担心的是您有很多内存可能是“陈旧的”(已分页),但在特定时间点您需要遍历所有内存,可能需要多次迭代并且您不想要内存要调出到磁盘的页面。

您将需要研究特定于平台的策略以提高性能。可以使用mlockallor将页面保存在内存中,VirtualLock但您确实不需要这样做。但是,请确保您知道将应用程序的内存页面锁定到 RAM 中的含义。您正在从其他进程中占用内存。

您可能还想研究低碎片堆(但它可能与此问题完全无关)以及描述与循环有关的缓存行的此页面。for

后一页是关于 CPU 在内存访问方面的工作原理(您通常不必关心的细节)。

示例 1:内存访问和性能与循环 1 相比,您希望循环 2 的运行速度快多少?

int[] arr = new int[64 * 1024 * 1024];

// Loop 1
for (int i = 0; i < arr.Length; i++) arr[i] *= 3;

// Loop 2
for (int i = 0; i < arr.Length; i += 16) arr[i] *= 3;

第一个循环将数组中的每个值乘以 3,第二个循环仅每 16 次乘一次。第二个循环只完成了第一个循环的 6% 左右的工作,但在现代机器上,两个 for 循环花费大约相同的时间:在我的机器上分别为 80 和 78 毫秒。

于 2011-04-16T02:16:09.613 回答
1

更新

vector< set<uint> > vec(node_vec.size());
for(uint i = 0; i < node_vec.size(); i++)
  for(uint j = i+1; j < node_vec.size(); j++)
    // some computation, basic math, store the result in variable x
      if( x > threshold ) {
         vec[i].insert(j);
         vec[j].insert(i);
      }

这仍然没有显示太多,因为我们不知道该条件多久x > threshold为真。如果x > threshold非常频繁地为真,那么这std::set可能是瓶颈,因为它必须为uint您插入的每个内容进行动态内存分配。

我们也不知道“一些计算”实际上是什么意思/做/是什么。如果它做得很多,或者以错误的方式做,这可能是瓶颈。

而且我们不知道您需要如何访问结果。

无论如何,预感:

    vector<pair<int, int> > vec1;
    vector<pair<int, int> > vec2;

    for (uint i = 0; i < node_vec.size(); i++)
    {
        for (uint j = i+1; j < node_vec.size(); j++)
        {
            // some computation, basic math, store the result in variable x
            if (x > threshold)
            {
                vec1.push_back(make_pair(i, j));
                vec2.push_back(make_pair(j, i));
            }
        }
    }

如果您可以使用该形式的结果,那么您就完成了。否则你可以做一些后期处理。只是不要将其复制到 a 中std::set(显然)。努力坚持std::vector<POD>。例如,您可以像这样在向量中建立索引:

    // ...
    vector<int> index1 = build_index(node_vec.size(), vec1);
    vector<int> index2 = build_index(node_vec.size(), vec2);
    // ...
}    

vector<int> build_index(size_t count, vector<pair<int, int> > const& vec)
{
    vector<int> index(count, -1);

    size_t i = vec.size();
    do
    {
        i--;
        assert(vec[i].first >= 0);
        assert(vec[i].first < count);
        index[vec[i].first] = i;
    }
    while (i != 0);

    return index;
}

ps.:我几乎可以肯定您的循环不受内存限制。但不能确定......如果你没有向我们展示的“节点”真的很大,它可能仍然是。


原答案:

没有简单I_will_access_this_frequently_so_make_it_fast(void* ptr, size_t len)的解决方案。

不过你可以做一些事情。

  1. 确保编译器可以“看到”在关键循环中调用的每个函数的实现。编译器能够“看到”实现所必需的取决于编译器。但是有一种方法可以确定:在循环之前inline在同一个翻译单元中定义所有相关函数,并将它们声明为.

    这也意味着您无论如何都不应该在那些关键循环中调用“外部”函数。“外部”函数是指系统调用、运行时库的东西或在 DLL/SO 中实现的东西。也不要调用虚函数,不要使用函数指针。而且或当然不分配或释放内存(在关键循环内)。

  2. 确保使用最佳算法。如果算法的复杂度高于必要,则线性优化没有实际意义。

  3. 使用尽可能小的类型。例如,不要使用intifsigned char来完成这项工作。这是我通常不会推荐的东西,但是在处理大量内存时,它可以大大提高性能。特别是在非常紧凑的循环中。

  4. 如果您只是复制或填充内存,请使用memcpyor memset。如果块大于大约 50 到 100 个字节,则禁用这两个函数的固有版本。

  5. 确保以缓存友好的方式访问数据。最佳方案是“流式传输” - 即使用升序或降序地址访问内存。您可以一次“跳”一些字节,但不要跳得太远。最糟糕的是随机访问一大块内存。例如,如果您必须处理二维矩阵(如位图图像),其中 p[0] 到 p[1] 是“向右”(x + 1)的一步,请确保内部循环递增 x 和外部增量 y。如果您以相反的方式执行此操作,则性能会差得多

  6. 如果您的指针没有别名,您可以告诉编译器(如何完成取决于编译器)。如果您不知道无别名意味着什么,我建议您搜索网络和编译器的文档,因为解释超出了范围。

  7. 如果合适,使用内部 SIMD 指令。

  8. 如果您知道在不久的将来需要哪些内存位置,请使用显式预取指令。

于 2011-04-16T03:06:15.103 回答
0

假设您在执行循环之前只从堆中分配一次数据,请注意,作为@lvella,内存就是内存,如果频繁访问它,则应该在执行期间有效地缓存它。

于 2011-04-16T02:16:11.783 回答
0

你不能用编译器选项来做到这一点。根据您的使用情况(插入、随机访问、删除、排序等),您可能会得到更合适的容器。

于 2011-04-16T02:07:39.857 回答
0

编译器已经可以看到数据在循环中被频繁访问。

于 2011-04-16T02:11:10.517 回答