Compiling Ceres with Schur specializations and Link Time Optimization
(LTO) results in warnings such as
/usr/include/eigen3/Eigen/src/Core/ProductEvaluators.h:31:8: warning: type ‘struct evaluator’ violates the C++ One Definition Rule [-Wodr]
31 | struct evaluator<Product<Lhs, Rhs, Options>> : public product_evaluator<Product<Lhs, Rhs, Options>> {
| ^
due to the redefinition of EIGEN_CACHEFRIENDLY_PRODUCT_THRESHOLD which
alters internal Eigen class definitions and consequently results in ODR
violations.
Avoid the ODR violation by renaming the Eigen namespace in translation
units that redefine EIGEN_CACHEFRIENDLY_PRODUCT_THRESHOLD.
While the issue is diagnosed in LTO builds of Ceres only, the problem
exists in non-LTO builds as well and per standard the compiler is not
even required to diagnose ODR issues. ODR violations constitute
undefined behavior.
Change-Id: Idf7c7a30cc8d3a86b0d62cbd33bef58783a62ee4
Stop linker emitting warnings such as
lto-wrapper: warning: using serial compilation of n LTRANS jobs
Change-Id: Ic933ef7b45955eabfa5b06e88cd195077ff9fc86
Using mold instead of GNU ld reduces the total build time by roughly
5-15 min. (depending on the load).
Change-Id: I66feab4e54c248cf92cc379d0085a93bdfdfef69
cuDSS could be used as an alternative for SuiteSparse and EigenSparse
in case if CUDA capable GPU is available.
Change-Id: I7a567093ce91363478118153e181134ed5804573
32-bit MinGW is being phased out:
https://www.msys2.org/news/#2023-12-13-starting-to-drop-some-32-bit-packages
With eigen3 and glog packages now removed, Ceres Solver no longer can be
built using stock MinGW. Therefore, we remove the support altogether.
Change-Id: I42d4ca3d15e7f3a5ddfa2eae409db7d87aed99ea
Instead of pre-computing pemutation from block-sparse to CRS order,
index of value in CRS matrix is computed in the process of updating
values using block-sparse structure.
When it is possible to update values via a simple host-to-device copy,
block-sparse structure on GPU is discarded after computing CRS
structure.
Computing index is significantly slower than using pre-computed
permutation, but is still hidden by host-to-device transfer.
On problems from BAL dataset this results into reduction of extra
gpu memory consumption from 33% (permutation stored as 32-bit indices)
to ~10% for storing block-sparse structure.
Benchmark results:
======================= CUDA Device Properties ======================
Cuda version : 11.8
Device ID : 0
Device name : NVIDIA GeForce RTX 2080 Ti
Total GPU memory : 11012 MiB
GPU memory available : 10852 MiB
Compute capability : 7.5
Warp size : 32
Max threads per block: 1024
Max threads per dim : 1024 1024 64
Max grid size : 2147483647 65535 65535
Multiprocessor count : 68
====================================================================
Running ./bin/evaluation_benchmark
Run on (112 X 3200 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x56)
L1 Instruction 32 KiB (x56)
L2 Unified 1024 KiB (x56)
L3 Unified 39424 KiB (x2)
Load Average: 24.58, 11.75, 8.52
-----------------------------------------------------------------------
Benchmark Time
-----------------------------------------------------------------------
Using on-the-fly computation of CRS index corresponding to block-sparse
index:
JacobianToCRS<g/final/problem-4585-1324582-pre.txt> 1607 ms
JacobianToCRSView<g/final/problem-4585-1324582-pre.txt> 564 ms
JacobianToCRSMatrix<g/final/problem-4585-1324582-pre.txt> 2226 ms
JacobianToCRSViewUpdate<g/final/problem-4585-1324582-pre.txt> 228 ms
JacobianToCRSMatrixUpdate<g/final/problem-4585-1324582-pre.txt> 400 ms
Using precomputed permutation:
JacobianToCRS</final/problem-4585-1324582-pre.txt> 1656 ms
JacobianToCRSView</final/problem-4585-1324582-pre.txt> 553 ms
JacobianToCRSMatrix</final/problem-4585-1324582-pre.txt> 2255 ms
JacobianToCRSViewUpdate</final/problem-4585-1324582-pre.txt> 228 ms
JacobianToCRSMatrixUpdate</final/problem-4585-1324582-pre.txt> 406 ms
Performance of JacobianToCRSViewUpdate is still limited by
host-to-device transfer, and JacobianToCRSView is faster than computing
CRS structure on CPU.
Change-Id: Ifb6910fb01ae6071400d36c277846fadc5857964
Since c++11, we can depend on C++ threads always being available.
With the recent work on the performance of CXX threading, the
additional complexity of maintaining multiple backends for some
minor performance delta is not worth it
https://github.com/ceres-solver/ceres-solver/issues/886
Change-Id: Idee480b22a498daec9c4366da8589aa58eaf36a1
The new SuiteSparse deployment bundles METIS 5.1.0 instead of 5.1.1 to
avoid heap corruption.
Fixes#918
Change-Id: Ie779dc2015c60e928c237529675e21d4635716a2
* Split `CERES_NO_METIS` into two defines: `CERES_NO_PARTITION` and
`CERES_NO_METIS`. The former refers to METIS support in SuiteSparse,
the latter to the Eigen's MetisSupport module. This enables the use of
sparse matrix reordering independent from SuiteSparse.
* Run Linux, macOS, and macOS Github workflows with METIS enabled
SuiteSparse.
Fixes#808
Change-Id: I5076b7e1268d32cc3e7e56650edcbaf7fb3b59ce
Previously, the tests did not run because the CMake version shipped with
Ubuntu 20.04 does not understand the `--test-dir` option and silently
fails.
Change-Id: I335e1d9e3890aa56e66a9dfd0fccd4594a84a08c
* Ubuntu 18.04 GCC does not fully support C++17, hence remove the
runner.
* Using CMake SuiteSparse in a C++17 project requires a workaround
implemented in a recent release.
Change-Id: I9985fe12d582dfc9b74e97d670828334e507e9f5
Sergiu Deitsch