【问题标题】:How to profile an optimized code and speed up loops如何分析优化的代码并加速循环
【发布时间】:2018-02-23 22:23:05
【问题描述】:

我知道对未经优化编译的代码进行分析没有多大意义,但是当我尝试使用-Ofast 对其进行编译并使用gprof 对其进行分析时,我变得毫无用处数据,例如许多具有相同 time% 而没有 calls# 信息的函数:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
 81.35      0.74     0.74                             void cv::Mat::forEach_impl<cv::Vec<unsigned char, 3>, A_estimation(cv::Mat&, std::vector<cv::Mat, std::allocator<cv::Mat> >, int, int)::{lambda(cv::Vec<unsigned char, 3>&, int const*)#1}>(A_estimation(cv::Mat&, std::vector<cv::Mat, std::allocator<cv::Mat> >, int, int)::{lambda(cv::Vec<unsigned char, 3>&, int const*)#1} const&)::PixelOperationWrapper::operator()(cv::Range const&) const
 10.99      0.84     0.10                             void cv::Mat::forEach_impl<cv::Vec<float, 3>, Parallel_process::operator()(cv::Range const&) const::{lambda(cv::Vec<float, 3>&, int const*)#1}>(Parallel_process::operator()(cv::Range const&) const::{lambda(cv::Vec<float, 3>&, int const*)#1} const&)::PixelOperationWrapper::operator()(cv::Range const&) const

当我分析未优化的代码时,我从gprof 获得了一个简单而有用的信息:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 53.86      0.07     0.07    42236     0.00     0.00  A_estimation(cv::Mat&, std::vector<cv::Mat, std::allocator<cv::Mat> >, int, int)::{lambda(cv::Vec<unsigned char, 3>&, int const*)#1}::operator()(cv::Vec<unsigned char, 3>&, int const*) const
 23.08      0.10     0.03  8259774     0.00     0.00  float const& cv::Mat::at<float>(int, int) const
  7.69      0.11     0.01  2812992     0.00     0.00  float& cv::Mat::at<float>(int, int)

这是我想找到的代码示例。我发现在它被称为46945 次的那部分代码中花费了53.86% 的时间:

我从我的代码中提取了该函数,以便您可以编译它:

#include <opencv2/highgui.hpp>
#include <iostream>

typedef std::vector<std::vector<int> > Matrix;

std::vector<int> A_estimation(cv::Mat& src_temp, std::vector<cv::Mat> rgb, int cols, int rows)
{
    //////////////////////////////
    //cv::Mat histSum = cv::Mat::zeros( 256, 1, CV_8UC3 );
    Matrix histSum(3, std::vector<int>(256,0));
    //cv::Mat src_temp = src.clone();
    //src_temp.convertTo(src_temp, CV_8UC3);    
    src_temp.forEach<cv::Vec3b>
    (
      [&histSum](cv::Vec3b &pixel, const int* po) -> void
      {
        ++histSum[0][pixel[0]];
        ++histSum[1][pixel[1]];
        ++histSum[2][pixel[2]];
      }
    );

    std::vector<int> A(3, 255);
    [&A, rows, cols, &histSum]{

        for (auto index=8*rows*cols/1000; index>histSum[0][A[0]]; --A[0])
             index -= histSum[0][A[0]];
        for (auto index=8*rows*cols/1000; index>histSum[1][A[1]]; --A[1])
             index -= histSum[1][A[1]];
        for (auto index=8*rows*cols/1000; index>histSum[2][A[2]]; --A[2])
             index -= histSum[2][A[2]];
        return A;
   }();
    return A;
        //auto AA=A_estim_lambda();
}

int main(int argc, char* argv[])
{
  cv::Mat src_temp = cv::imread(argv[1]);
  auto rows=src_temp.rows,
       cols=src_temp.cols;
  std::vector<cv::Mat> rgb;
  cv::split(src_temp, rgb);
  auto A = A_estimation(src_temp, rgb, cols, rows);

  //Do sth with A
}

编译:

g++ -std=c++1z -Wall -Weffc++ -Ofast test.cpp -o test -fopenmp `pkg-config --cflags --libs opencv`

执行

./test frame.jpg 

我有两个问题:

这些信息是否正确,因为它们取自非优化代码,如果不正确,我该如何编译优化代码?以及如何加快这些循环的任何提示?

【问题讨论】:

  • 请发帖minimal reproducible example。现代编译器为这类事情生成最佳代码。加速它的最大希望是,如果您可以重构数据,以便连续的内存访问往往会命中相同的缓存行。
  • 分析未优化的代码是徒劳的。您需要对实际应用程序进行概要分析,并进行全面优化。
  • 加速未优化代码的方法是对其进行优化。 :-) 否则你可能会成为The Streetlight Effect 的受害者 - 搜索容易看到的东西。猜测是Mat::at 访问器在调试模式下进行范围检查,这就是它们出现在该列表中的原因。让它们更快不会帮助生产代码。
  • @JiveDadson 我刚刚添加了该代码的示例..
  • @BoPersson 是的,这是我的问题,我该如何正确编译/配置它!

标签: c++ profiling gprof


【解决方案1】:

你有相反的观点吗?

首先,加速分为两类:编译器可以解决的问题,以及只有您可以解决的问题。优化器不会修复只有你能修复的东西。此外,它不会让它们脱颖而出,因为加速不会加在一起,它们会成倍增加。

其次,考虑数字——时间的百分比或分数。 如果您可以修复加速(可能有几个),则需要一定的时间。比如说 30%。
这意味着如果您可以完全删除它,代码将运行 70% 的时间。加速因子将为 100/70 或 1.43 倍。
这也意味着,如果您只是手动暂停程序,随机,它有 30% 的机会正在做浪费的事情
因此,如果您只是手动暂停它 20 次(不是很多),那么浪费的东西将出现大约 6 次。如果您发现它做了一些可以在多次暂停时得到改进的东西,无论您如何描述它,您都发现了加速。
当然,它可能只浪费了 25%,或者多达 35%,但你在乎吗?提示:不,你不在乎,因为你发现了问题,这比确切知道它的成本更重要。

这就是您获得多次加速这一事实真正得到回报的地方。您修复的每个加速不仅可以节省一些时间。它乘以两件事:它乘以总加速因子,乘以每个剩余问题所花费的时间分数,使它们更加突出。

这就是 this approach 背后的原因。

一旦你修复了你的加速,让优化器来做它的加速。

【讨论】:

    猜你喜欢
    • 2018-10-15
    • 2011-03-12
    • 1970-01-01
    • 1970-01-01
    • 2011-10-12
    • 1970-01-01
    • 2016-08-01
    • 2020-02-18
    • 1970-01-01
    相关资源
    最近更新 更多