Closed zwn closed 3 years ago
Hello!
Yes this is expected. The first version of srrg_proslam
was designed in a end-to-end fashion and, hence, the implementation was overfitted to the VO problem. In this case, instead, the huge gain in flexibility requires is paid with a code overhead, which impacts on the fps (still above real-time).
I see big difference in speed comparing
srrg2_proslam
andsrrg_proslam
- 40fps vs 60fps. Is that expected? Both were compiled without-march=native
.