对于小图像，多线程对StereoBM无效

Question

我在ARM Cortex-A7（Raspberry Pi 2）上与OpenCV的StereoBM进行立体匹配。我仅限于CPU处理，因此加快速度的唯一方法是将分辨率降低到QVGA甚至QQVGA。我想尽快处理。由于图像非常小，StereoBM往往只使用1或2个线程而不是4个。

在stereobm.cpp：

中计算默认的线程数

double N0 = 8000000 / (useShorts ? 1 : 4);  // approx tbb's min number instructions reasonable for one thread
double maxStripeSize = std::min(std::max(N0 / (width * ndisp), (wsz-1) * SAD_overhead_coeff), (double)height);
int nstripes = cvCeil(height / maxStripeSize);

基本上，图像被分成条带，然后用parallel_for_处理。我不知道maxStripeSize背后的想法，但它可能正在尝试根据各种参数（差异数等）优化线程大小，它可能适用于更大的图像。

我可以通过设置nstripes变量强制执行固定数量的线程。我用StereoBM测量了以下内容：

sub-QVGA（320x158）：

• 1个线程= ~90ms
• 2个主题（OpenCV默认）= ~50ms
• 4个线程强制= ~50ms

QQVGA（160x120）：

• 1个线程（OpenCV默认值）= ~20ms
• 4个线程强制= ~20ms

可以清楚地看到QVGA和QQVGA在4个线程上没有加速。为什么？我怀疑并行化开销对于小数据来说可能太大，因此无效。从我的测试中，对于多线程来说，更大的图像往往更有效。

我仅限于在当前的硬件设计中使用CPU。有没有办法如何更有效地使用所有4个CPU内核或更快地处理立体声？ GPGPU（CUDA或OpenCL）在使用这些小图像时会表现得更好吗？我想雇用实时愿景。一种可能的解决方案可能是将StereoBM重写为FPGA，但我想避免这种情况。

配置说明：使用OpenCV 3.0.0。我测试了TBB和PTHREADS，它们似乎与线程相同。此外，我在OpenCV中启用了NEON和VFPV3（即使RPi2似乎使用VFPV4）。