我知道在没有优化的情况下编译已编译的代码但在我尝试使用-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)
这是我想要找到的热门代码示例。我发现在53.86%
次调用代码的那部分时间需要46945
次:
我从我的代码中提取了该函数,以便您可以编译它:
#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
我有两个问题:
这些信息是否正确,因为它们来自非优化代码,如果不是,我如何编译优化代码?以及如何加快这些循环的任何提示?
答案 0 :(得分:3)
你是否有相反的观点?
首先,加速分为两类:编译器可以修复的东西,以及只有你可以修复的东西。优化器不会修复只能修复的东西。此外,它不会让它们脱颖而出,因为加速不会加在一起,它们会成倍增加。
其次,考虑数字 - 百分比或时间的分数。
如果有一个加速你可以修复(有可能有几个),它需要一定的时间。比如说30%
这意味着如果您可以完全删除它,代码将在70%的时间内运行。加速因子将是100/70或1.43x
这也意味着如果你只是随机地手动暂停程序,那么在做浪费的事情的过程中,它将是的几率为30%。
因此,如果您只是手动暂停20次(不是很多),那么浪费的东西大约会出现6次。如果你看到它做了一些可以在多次停顿时做出改进的事情,无论你怎么形容它,你都发现了加速。
当然,它可能只浪费25%,或多达35%,但你关心吗?提示:不,你不关心,因为你发现问题,这比确切知道它的成本更重要。
这就是你有多次加速的事实真的得到了回报。你修复的每个加速都不仅节省了一些时间。它乘以两件事:它乘以总加速因子,并将每个剩余问题所花费的时间乘以它们,使它们更加突出。
这就是this approach背后的原因。
一旦你修复了你的加速,请让优化器加速。