相关疑难解决方法(0)

我有一个在Linux上运行的C++应用程序,我正在优化它.如何确定代码的哪些区域运行缓慢？

描述

当使用openmp的parallel for construct分配和释放具有4个或更多线程的随机大小的内存块时,程序似乎开始在测试程序的运行时的后半部分泄漏大量内存.因此,它消耗的内存从1050 MB增加到1500 MB或更多,而无需实际使用额外的内存.

由于valgrind没有显示任何问题,我必须假设看起来像是内存泄漏实际上是内存碎片的强调效果.

有趣的是,如果2个线程分别进行10000次分配,则效果尚未显示,但如果4个线程分别进行5000次分配则显示效果很强.此外,如果分配的块的最大大小减少到256kb(从1mb),则效果会变弱.

重型并发能否强调碎片那么多？或者这更可能是堆中的错误？

测试程序说明

构建演示程序是为了从堆中获取总共256 MB的随机大小的内存块,进行5000次分配.如果达到内存限制,则首先分配的块将被释放,直到内存消耗低于限制.执行5000次分配后,将释放所有内存并结束循环.所有这些工作都是针对openmp生成的每个线程完成的.

这种内存分配方案允许我们预计每个线程的内存消耗约为260 MB(包括一些簿记数据).

演示计划

由于这是您可能想要测试的内容,您可以使用dropbox中的简单makefile下载示例程序.

按原样运行程序时,您应该至少有1400 MB的RAM可用.您可以随意调整代码中的常量以满足您的需求.

为完整起见,实际代码如下:

#include <stdlib.h>
#include <stdio.h>
#include <iostream>
#include <vector>
#include <deque>

#include <omp.h>
#include <math.h>

typedef unsigned long long uint64_t;

void runParallelAllocTest()
{
    // constants
    const int  NUM_ALLOCATIONS = 5000; // alloc's per thread
    const int  NUM_THREADS = 4;       // how many threads?
    const int  NUM_ITERS = NUM_THREADS;// how many overall repetions

    const bool USE_NEW      = true;   // …

我想使代码低于并行化:

for(int c=0; c<n; ++c) {
    Work(someArray, c);
}

我这样做了:

#include <thread>
#include <vector>

auto iterationsPerCore = n/numCPU;
std::vector<std::future<void>> futures;

for(auto th = 0; th < numCPU; ++th) {
    for(auto n = th * iterationsPerCore; n < (th+1) * iterationsPerCore; ++n) {
        auto ftr = std::async( std::launch::deferred | std::launch::async,
            [n, iterationsPerCore, someArray]()
            {
                for(auto m = n; m < n + iterationsPerCore; ++m)
                    Work(someArray, m);
            }
        );
        futures.push_back(std::move(ftr));
    }

    for(auto& ftr : futures)
        ftr.wait();
}

// rest of iterations: n%iterationsPerCore …

过去一周我一直在写一个光线跟踪器,并且已经达到了足够多线程有意义的程度.我已经尝试使用OpenMP来并行化它,但是用更多线程运行它实际上比用一个线程运行它要慢.

阅读其他类似问题,特别是有关OpenMP的问题,一个建议是gcc更好地优化串行代码.但是,运行下面的编译代码的export OMP_NUM_THREADS=1速度是以下的两倍export OMP_NUM_THREADS=4.即两次运行的编译代码相同.

运行程序time:

> export OMP_NUM_THREADS=1; time ./raytracer
real    0m34.344s
user    0m34.310s
sys     0m0.008s


> export OMP_NUM_THREADS=4; time ./raytracer
real    0m53.189s
user    0m20.677s
sys     0m0.096s

用户时间比实际小很多,这在使用多个核心时很不寻常 - 用户应该比实际大,因为多个核心同时运行.

我使用OpenMP并行化的代码

void Raytracer::render( Camera& cam ) {

    // let the camera know to use this raytracer for probing the scene
    cam.setSamplingFunc(getSamplingFunction());

    int i, j;

    #pragma omp parallel private(i, j)
    {

        // Construct a ray for each pixel.
        #pragma omp for …