使用openMP的for循环运行速度比串行代码慢

Question

I have a piece of code which I am trying to run in parallel, however, for some reason it does not increase speed.

The code performs matching between a set of newly found keyPoints and older found keyPoints and thereafter RANSAC is performed in 500 iterations.

Since each pair works independent of each other, I would expect that doing the matching and RANSAC would increase speed quite a lot.

Here is the code:

Eigen::VectorXf RigidChainTracker::GPUgetCamera(cv::Mat depthNew, cv::Mat colorNew, cv::Mat grayNew, deque<imgPair> oldImg, const Eigen::VectorXf &XiInit,
    vector<cv::KeyPoint> foundPtsNew, cv::Mat descriptorNew, const float alpha){

    vector<cv::KeyPoint> matchedOld[CHAINLENGTH];
    vector<cv::KeyPoint> matchedNew[CHAINLENGTH];

    FindFeatures::FindFeatures fFeatures[CHAINLENGTH];
    for (int i = 0; i < CHAINLENGTH; ++i){
        fFeatures[i] = FindFeatures::FindFeatures(METHOD, fx, fy, cx, cy);
    }
    double t1 = omp_get_wtime(); 
    int i = 0;
    int chainlength = CHAINLENGTH;
    vector<cv::KeyPoint> keyPtsNew[CHAINLENGTH];
    vector<cv::KeyPoint> keyPtsOld[CHAINLENGTH]; 
    const float THRESHOLD = 0.02;
    Eigen::Matrix3f Rrel[CHAINLENGTH];
    Eigen::Vector3f trel[CHAINLENGTH];

#pragma omp parallel for private (i) shared(fFeatures,matchedNew, matchedOld, depthNew, colorNew, grayNew, oldImg,descriptorNew,foundPtsNew, keyPtsNew, keyPtsOld,Rrel,trel, chainlength, THRESHOLD) 
    for (i = 0; i < chainlength; ++i){
        if (i < oldImg.size()){
            fFeatures[i].MatchFeatures(depthNew, oldImg[i].depth, descriptorNew, oldImg[i].descriptor, foundPtsNew, oldImg[i].foundPts, keyPtsNew[i], keyPtsOld[i]);
            fFeatures[i].RANSAC3D(depthNew, oldImg[i].depth, keyPtsNew[i], keyPtsOld[i],  Rrel[i], trel[i],THRESHOLD);


            matchedNew[i] = keyPtsNew[i]; 
            matchedOld[i] = keyPtsOld[i];
        } 
    }

When running this in serial, it runs in about 2-5 Hz, but with OpenMp slightly slower. I have tried some different things, but I cannot get it right. Can it be something strange when trying to read from the same memory, like when reading from depthNew or descriptorNew. I write information to keyPtsNew, keyPtsOld, matchedNew, matchedOld, Rrel, and trel in MatchFeatures and RANSAC3D. From the images depthNew and descriptorNew, I only read information. Is it really possible that serial code is faster?

I have confirmed that multiple threads are executing and the openMP flag in visual studio is enabled. :)

I have tried the suggestion by Avi Ginsburg, and it speeds up the parallel part a bit, but the serial code is still faster.

I timed the tow different functions MatchFeatures and RANSAC3D. When running in serial, each task takes about 0.05 seconds at most.

When running in parallel, each task needs between 0.1 and 0.15 seconds, considerably slower. I am trying to figure out if there is some parallelization performed by OpenCV that I do not know about. For example in the matching process or whatever.

/ Erik

Answer 1

Erik, it is POSSIBLE that a serial code would run faster than a parallel one, due to CACHE and pipelining optimizations performed by the compiler.

In your case it seems to be the case due to the large number of variables shared between threads. Shared variables have an synchronization overhead that compromise your performance. I believe it can be fixed by breaking the OMP loop into two sections. The first one performs the calculations and creates a new array of results. The second one loops through the old and new array performing the match.

In parallel programming, the time costs of transferring values from memory to CACHE and registers are often so big due to device latency and band limitations, that it may be worth it to simply copy data to CACHE of each thread, compute it, and then reduce the result, instead of continuously sharing it among threads and processes to avoid duplication. It means that less-memory-optimized code sections might actually improve performance.

Answer 2

You have what appears to be a case of false sharing . In short, that means that one threads cached objects are becoming invalid by another caches object on the same cache line. The simplest way to solve this (IMO) is to rewrite the function as:

Eigen::VectorXf RigidChainTracker::GPUgetCamera(cv::Mat depthNew, cv::Mat colorNew, cv::Mat grayNew, deque<imgPair> oldImg, const Eigen::VectorXf &XiInit,
    vector<cv::KeyPoint> foundPtsNew, cv::Mat descriptorNew, const float alpha)
    {


    vector<cv::KeyPoint> matchedOld[CHAINLENGTH];
    vector<cv::KeyPoint> matchedNew[CHAINLENGTH];

    // Use thread local variables to avoid conflicts
    #pragma omp parallel shared(depthNew, colorNew, grayNew, oldImg,descriptorNew,foundPtsNew) 
    {
        vector<cv::KeyPoint> matchedOld_local[CHAINLENGTH];
        vector<cv::KeyPoint> matchedNew_local[CHAINLENGTH];

        FindFeatures::FindFeatures fFeatures[CHAINLENGTH];
        for (int i = 0; i < CHAINLENGTH; ++i){
            fFeatures[i] = FindFeatures::FindFeatures(METHOD, fx, fy, cx, cy);
        }
        double t1 = omp_get_wtime(); 
        int i = 0;
        int chainlength = CHAINLENGTH;
        vector<cv::KeyPoint> keyPtsNew[CHAINLENGTH];
        vector<cv::KeyPoint> keyPtsOld[CHAINLENGTH]; 
        const float THRESHOLD = 0.02;
        Eigen::Matrix3f Rrel[CHAINLENGTH];
        Eigen::Vector3f trel[CHAINLENGTH];

    #pragma omp for 
        for (int i = 0; i < chainlength; ++i)
        {
            if (i < oldImg.size())
            {
                fFeatures[i].MatchFeatures(depthNew, oldImg[i].depth, descriptorNew, oldImg[i].descriptor, foundPtsNew, oldImg[i].foundPts, keyPtsNew[i], keyPtsOld[i]);
                fFeatures[i].RANSAC3D(depthNew, oldImg[i].depth, keyPtsNew[i], keyPtsOld[i],  Rrel[i], trel[i],THRESHOLD);


                matchedNew_local[i] = keyPtsNew[i]; 
                matchedOld_local[i] = keyPtsOld[i];
            } 
        }

    // Copy to the global variable here
    #pragma omp critical
        {
           for (int i = 0; i < chainlength; ++i)
            {
                if (i < oldImg.size())
                {
                   matchedNew[i] = matchedNew_local[i]; 
                   matchedOld[i] = matchedOld_local[i];
               }
           }            
        }
    }

Note that if any of your shared variables are changed in the for loop, all the threads have to discard their cached version until the updated version is fetched.

Also, as the only changed parameters that I saw were matchedNew and matchedOld , those were the only ones that I declared as thread local vs. global. If there are others ( fFeatures ?) that need to be used by the master thread later or returned, declare local/global versions of them and copy them in the critical section.