I made a quick test (no loops, but some iterations manually) for Canny and GaussianBlur inside my image processing library at work. My system is a i7 7700 with 4 cores and 8 threads on Windows with Visual Studio 2015. I used a random grayscale image with 4MP. The results are:
Canny:
- 1 thread 13.5ms
- 2 threads 9ms
- 4 threads 6.5ms
- 8 threads 6.5ms
And for GaussianBlur:
- 1 thread: 4ms
- 2 threads: 3ms
- 4 threads: 2ms
- 8 threads: 1ms
For parallel GaussianBlur I used this implementation:
class ParallelGaussianBlurImpl_ : public ParallelLoopBody
{
public:
ParallelGaussianBlurImpl_(const Mat &_src, Mat &_dst, Size _kSize, double _sigmaX, double _sigmaY, int _borderType) :
src(_src), dst(_dst), kSize(_kSize), sigmaX(_sigmaX), sigmaY(_sigmaY), borderType(_borderType)
{}
ParallelGaussianBlurImpl_& operator=(const ParallelGaussianBlurImpl_&) { return *this; }
inline void operator()(const Range &r) const {
cv::GaussianBlur(src.rowRange(r.start, r.end), dst.rowRange(r.start, r.end), kSize, sigmaX, sigmaY, borderType);
}
private:
const Mat &src;
Mat &dst;
Size kSize;
double sigmaX, sigmaY;
int borderType;
};
void parallelGaussianBlur(InputArray _src, OutputArray _dst, Size kSize, double sigmaX, double sigmaY, int borderType) {
const int numThreads = ocl::useOpenCL() ? 1 : max(1, min(getNumThreads(), getNumberOfCPUs()));
if(numThreads == 1 || borderType & BORDER_ISOLATED) {
cv::GaussianBlur(_src, _dst, kSize, sigmaX, sigmaY, borderType);
} else {
_dst.create(_src.size(), _src.type());
Mat src = _src.getMat(), dst = _dst.getMat();
parallel_for_(Range(0, _src.rows()), ParallelGaussianBlurImpl_(src, dst, kSize, sigmaX, sigmaY, borderType), numThreads);
}
}
It seems that Canny does not scale that good with hyperthreading, but GaussianBlur do. It's possible, that some other processes falsify the test a bit, but the tendency is unambiguous.
Did you make tests with setNumThreads() or just with different builds?
EDIT: whatever comes to my mind: You said that you are working in a VM. Check if you set the number of cores in your VM > 1. Otherwise I have no more ideas.
check the cmake output (or cv::getBuildInformation()). there should be a
Parallel framework:entrycv::getBuildInformation() gives me: Parallel framework: OpenMP
What OpenCV version do you use?
In OpenCV 2.4 Canny isn't parallelized at all. Even in OpenCV 3.0 and 3.1 Canny is only parallelized with TBB and not with OpenCV's parallel framework (including OpenMP).
Another thing is, if you use
cv::UMat, OpenCL is prefered before CPU implementation.Next I don't know if IPP works with ARM processors. If so, and your OpenCV version is 3.2, IPP will always be prefered when using
apertureSize=3andL2gradient=false. In this case you can setL2gradient=trueto get multithreading support with OpenMP.^^ imho, that would would have been a perfect answer !
Thanks for the answer matman | I´m using OpenCV 3.2. | I don´t use OpenCLs UMat | i set L2gradient=true but there is no improvement regards to speed between OpenMP version and the "normal" build | I tried to do the same task with TBB on: I build the library with -DWITH_TBB=ON and -DBUILD_TBB=ON but the timinganalysis is the same (no difference when using gauss, canny, median), after that I build the library for the Intel i7 with the TBB support but on this system these filters also get no benefit
cv::medianBlurisn't parallelizied at all. In OpenCV 3.3cv::GaussianBluris only parallelized with IPP (but disabled?). I don't know how it is done in 3.2. It should be possible to split the image into stripes and process each stripe in a thread independently.For
cv::Cannyyour results are odd. There should be at least a performance difference when setting different number of threads. Can you make a debug-build and debug into the functions to check if multithreading works correct? And please check whatcv::getNumberOfThreads()returns. Try to set the number of threads to the number of your physical CPU cores (not logical).When you use Windows and you don't set a multithreading library I think the Concurrency framework is used. Please check this in your "normal build", too.
cv::getNumberOfThreads() returns 4 (i´m running a Linux VM with 4 Cores) | when debuging the programm steps into (with TBB on): parallel_for_(Range(0, src.rows), parallelCanny(src, map, low, high, aperture_size, L2gradient, &borderPeaksParallel), numOfThreads); Do you get a time change for the Cannyruntime when you are building you library with TBB support? | if I run my normal build pthread is active, when i run canny with the "normal" build it needs 0.00478609 sec but when set it down to 1 canny needs 0.00427457, so its faster when not parallelized?