メモです。
チラシの裏です。

表題の通りです。
opencv_traincascade.exeのソースコードを見たらTBBを生で使ってマルチスレッド処理をしてましたので、これだけのためにTBB込みのビルドをしたら、とてもはかどりました。

-precalcValBufSize と -precalcIdxBufSize もデフォルトですと1024なのですが、これを4096とかにすると、さらにはかどりました。

OpenCV3では、パラレルフレームワークはラップされており、特にWindowsでは、TBBはあんまり早くないということで、この頃はCMAKEオプションに入れませんし、デフォルトでOFFですが、こういうコードも残っているのですね。
しかしながら、コード修正したり、PRしたりする実力はないので、場当たり的にTBBを有効にして対処しました。

世の中3.3なのに、HAVE_TBBとかおくれてますねえ。

私が試した感じでは、正解1000枚、不正解230枚くらいで15ステージだと、メモリのサイズを大きくすると時間が半分くらいになり、さらにTBBを使うとその3/4くらいになります。

さらに場当たり的なことを思いつきました。opencv_traincascade.exeだけTBBを有効にしてコンパイルしたら良いかも！(ソースコードは触りたくない男！)

さらにJPEGをTurboJPEGに差し替えたり、ZLIBをアセンブラつかっているバージョンに差し替えればさらに幸せになれそう！

ということで、ZLIBとJPEGを差し替え、opencv_traincascade.exeだけTBBを有効にしてチャレンジしたら、また少し早くなりました。20ステージで32分だったのが24分になりました。
しかし、こんな場当たり的なやり方では、
・ZLIBを差し替えたからPNGの展開が早くなった
・LIBJPEGを差し替えたからJPEGの展開が早くなった
・OPENCVのライブラリは標準のパラレルが効いていて、かつopencv_traincascade.exeではTBBが効いているので早くなった
どれが効いたのか全くわかりませんね。。場当たり的で、なんとなく早くなったという、インドの究極奥義バータリーと言えます。
思いつきでなんとなくウマくいったという話です。

ご参考まで。