-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 209 cpu timer #5
base: master
Are you sure you want to change the base?
Conversation
parallel_for_(cv::Range(0, 2), [&](const cv::Range& range){ | ||
for (int i = range.start; i < range.end; i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, does this spawn 2 threads, or 3 threads (where the 3rd thread fails the for
guard immediately)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cv::Range
is inclusive of the lower-bound and exclusive of the upper-bound, so the range contains 0 and 1.
This sounds like a nice improvement (maybe as its own PR) as long as updating OpenVINS with upstream changes isn't affected too much. |
If the size will ever greater than 2 (swapchains?), then this is likely worth it. |
It's not swapchains; it's the number of eyes on the stereo camera. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good in general. My only concern is that the threading changes will make rebasing on top of latest OV more painful. But I wonder if mainline OV will be willing to accept the threading changes (I think they are good for them too). Would you like to ask them?
rT2 = boost::posix_time::microsec_clock::local_time(); | ||
|
||
{ | ||
#ifdef ILLIXR_INTEGRATION | ||
CPU_TIMER_TIME_BLOCK("preform_detection"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perform
// Disabling OpenCV threading is faster on x86 desktop but slower on | ||
// jetson. Keeping this here for manual disabling. | ||
// cv::setNumThreads(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's useful to keep this around.
See upstream, open_vins #167. |
Once #3 is merged, the target branch should change (done).
This PR fixes #2 and fixes #4. It's not too much trouble to review them simultaneously.
I elected to use OpenCV
parallel_for_
because it means I wouldn't have to implement my own threadpool, bring in the multithread queue, it responds to the samecv::setNumThreads
, and its two-level for-loop unifies the single-threaded and mult-threaded cases.When numthreads is greater than 2, the ranges will be [0, 1] and [1, 2], so one thread will go
for (size_t i = 0; i < 1; ++i)
(akai
gets 1, and then terminates).In many places we have
i == 0 ? img0 : img1
. A slightly better way of doing this would be:std::array<Img, 2> imgs;
andimgs[i]
, but this would require changing every usage of these in the rest of OpenVINS, which I considered too burdensome.The reviewer should:
std::array<T, 2>
trick or others are worth it or worth it in specific cases.