After the last Noetic release of this week, now I’m glad to announce that GTSAM is finally available in all active ROS 1 and ROS 2 distributions as a package ready to install as easy as:
sudo apt install ros-$ROS_DISTRO-gtsam
So, if you are using this great factor graph C++ library in your SLAM / Visual-Inertial Odometry package as a git submodule, feel free of replacing it by just a new dependency line in the package package.xml file: <depend>gtsam</depend>.
Note that, unlike what happens if you directly clone the gtsam repo in your workspace and build it, the official builds from ROS build farms will already come with the problematic cmake flag GTSAM_USE_SYSTEM_EIGEN set to ON thanks to commits like this in the gbp repos for all distributions.
Feel free of testing these new packages and report any issues you find.
We always compiled gtsam from source to get CPU -specific optimizations. Do the released packages use a reasonable set of flags so that speed wouldn’t degrade?
Good point. The main limitations here are, as you probably know since you worry about this:
Optimizing for a “higher” set of intrinsics (e.g. AVX512 vs AVX or AVX2) means that users with a “lower” CPU will find crashes,
Using -march=native is not safe since we don’t know in advance the architecture of the builders, and
Memory alignment of Eigen3’s structures require all libraries and programs to be built with the same set of flags (at least, those that affect the alignment, like the available sets of intrinsics). In principle, this is solved in GTSAM via cmake “PUBLIC” flags. But user programs will then find those flags “magically” appearing in their builds without knowing that they come from compiling/linking against gtsam.
So, the maybe conservative flags you ask for in the current ROS builds of GTSAM include -O2, and -flto=auto, but have no explicit enabling of other vectorization instructions.
However, in these topics it’s always better to just benchmark, benchmark, and benchmark to know which build is faster and how much is gained/lost, so if you have a chance to do the experiment, I would be glad the read the results.
And of course, if we see that additional flags would be better, I would be happy to add them for next builds. Maintaining a package is only useful if the package does serve a purpose and solves a problem…
We use it nightly on 8 platforms using x86 and aarch64 finding improvements and regressions in both performance and functionality for various CPU packages. View performance results we measure.
