1. Add abseil-cpp as a submodule. We are tracking the latest LTS
release, which is lts_2024_01_16.
2. Replace glog/gflags with absl::log and absl::flags.
3. Remove miniglog
4. Also take a whack at making the bazel build work with
abseil-cpp and gtest.
There are a number of TODOs in this CL that still need to be resolved.
Change-Id: I39355ed7d61375be4ebcbc8596d9cc70acc1c678
cuDSS could be used as an alternative for SuiteSparse and EigenSparse
in case if CUDA capable GPU is available.
Change-Id: I7a567093ce91363478118153e181134ed5804573
We now use googletest as a git submodule instead
of the old way of converting it into a single header
and including it in the source.
This removes the dependence on googleflags for tests
to be enabled.
Change-Id: If25ea3ba7a39c2b8ba9c6effbed3e7173361b6b1
Compilation fails if the CUDA architecture is not supported by the
installed version of the CUDA toolkit. This commit sets the
CMAKE_CUDA_ARCHITECTURES depending on the the installed CUDA toolkit
version.
Change-Id: I4765512279ee56897388e6ea22b961aebeb0fbca
The CellInfo struct contains a mutex, which interacts poorly
with some standard library containers which may move things around.
As a result we were using std::unique_ptr<CellInfo> in these
containers, but this change gets rid of that level of indirection
as std::unordered_map can construct CellInfo in place and we can
replace the use of std::vector with an array we know will not be
resized.
This improves the performance of the schur eliminator a bit but
also the performance of the block diagonal preconditioners.
Change-Id: If3ccd1273a754d9c5112e6e611ce31066b6b27b5
This avoids warnings such as
D:\a\ceres-solver\ceres-solver\internal\ceres\cuda_kernels_bsm_to_crs.cu.cc(143): warning #550-D: variable "row_nnz_e" was set but never used [D:\a\ceres-solver\ceres-solver\build_Release\internal\ceres\ceres_cuda_kernels.vcxproj]
int row_nnz_e = 0;
^
detected during instantiation of "void ceres::internal::RowBlockIdAndNNZ(int, int, int, const int *, const ceres::internal::Cell *, const ceres::internal::Block *, const ceres::internal::Block *, int *, int *, int *) [with partitioned=false]" at line 240
Remark: The warnings can be suppressed with "-diag-suppress <warning-number>"
that is caused by compile-time conditional use of the variable.
Change-Id: I041b076a5208eeb662b8c7500d7b238965be833c
std::copy_n is defined in <algorithm>, which is not explicitly included
and therefore causes compilation errors with the recent GCC 14.1 and/or
CUDA 12.4.1.
Change-Id: I9fcab48770ccfc5ec195dca5a190ceaad9debe81
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
Fixes the following two warnings:
preconditioner.h:64:11: warning: field 'f_block_size' will be initialized after field 'elimination_groups' [-Wreorder-ctor]
block_sparse_matrix.cc:70:19: warning: unused parameter 'values' [-Wunused-parameter]
Change-Id: I5cc55ca387b3f12259096c1531c263279650bd49
This reverts commit 4027f69975.
Reason for revert: This breaks the build because this constructor syntax is only present in the unstable/development version of eigen. So the macro check is incorrect.
Change-Id: I1e664208c7c50041e295aeb7c4b65259f9f2fc8f
This function is not used and is not written correctly to
deal with the case wherre Schur specialization is disabled.
Change-Id: I48509317e6df5f9cdc37c81e879fad425bb2d037
If arguments are passed to a cost function that can be used to construct
the functor, the latter will be instantiated by the cost function using
std::make_unique to ensure exception safety. This not only avoids static
analysis warnings caused by calling new but also spelling the cost
functor type name multiple times.
Also expand deduction guides for instantiating
Dynamic(Auto|Numeric)DiffCostFunction from std::unique_ptr enabled
constructor overloads.
Finally, make CostFunction default move constructible and assignable but
only through derived classes. This in turn allows derived classes to be
movable without relying on custom implementations of corresponding
operators.
Change-Id: Idee8b9871d862bc9f9f8b5a8d0bedc52863e93c0
Move Bessel functions availability checks from configuration time to
inclusion time to be more robust and allow the use of ABI compatible
compilers (e.g., Ceres is compiled using Clang but is used in a project
compiled using GCC.)
Since libc++ does not yet implement special math functions, we fallback
to their POSIX implementation if available. However, then only the
deprecated BesselJ{0,1,n} are provided.
Fixes#814
Change-Id: Ic3e62452b36e90cb22644cc8e553e3dd1881193f
Starting Ubuntu 20.04, TBB is shipped with a native CMake package
configuration making the find module contained in Ceres no longer
necessary.
Fixes#1036
Change-Id: Ia1a18d004aa53dd0b654a8cd94daea60ea1feb98
This eliminates an entire vector and computation of a square root
followed by a squaring.
Thanks to @rlabbe for pointing this out.
Change-Id: I0de117b31b9332c61e687f18466d7cb2e2ac611e
As pointed out by several users, introduction of parallel operations on
vectors severely impacts solver performance on small problems, with time
consumption increasing with the number of threads.
In order to minimize overhead of trying to execute small tasks using a
large number of threads, task scheduling mechanism was changed to avoid
scheduling all tasks at once.
However, there is still a large difference in exectuion time because the
main thread always launches the next thread before starting doing the
work. This leads to several orders of magnitude slowdown when going from
a single-threaded execution (which follows a fast-forward path to a
single loop over all indices, without any synchronization involved)
to a two-thread execution:
/bin/parallel_vector_operations_benchmark
-------------------------------------------
Benchmark Time
-------------------------------------------
SetZero/128 12.8 ns
SetZeroParallel/128/1 16.6 ns
SetZeroParallel/128/2 2211 ns
In order to eliminate this effect, we limit the block-size of parallel
execution of vector operations to 2^16 elements (thus, starting parallel
execution only for vectors of at least 2^17 elements).
Threshold of 2^16 elements was choosen by evaluating thresholds from
2^10 to 2^20 (only powers of 2), with 2^14..2^20 significantly reducing
worst-case runtime degradation.
Details can be found in discussion of the issue at
https://github.com/ceres-solver/ceres-solver/issues/1016
Change-Id: I555c882d63ee53323ceb426743b970f989b65503
As pointed out by several users, introduction of parallel operations on
vectors severely impacts solver performance on small problems, with time
consumption increasing with the number of threads.
The problem is two-fold:
- Single-threaded execution is faster than multi-threaded
- Overhead of multi-threaded execution increases dramaticaly when
number of threads is increased
Supposedly, the second problem is due to ParallelInvoke scheduling
a task for each thread via ThreadPool.
When the time required to perform computations is smaller than costs of
scheduling task, runtime becomes linear in num_threads.
Moreover, main thread competes with working threads for mutex in
ConcurrentQueue.
In order to limit scheduling overhead and minimize lock contention,
each new task is scheduled from the previous one, if:
- Number of scheduled tasks is less than num_threads
- At the moment of creating the task not all work has been done
Correctness is granted by atomicity of thread_id counter.
SchedulerBenchmark mini-benchmark was added to illustrate the issue.
Each iteration of parallel loop performs change of a single value.
With the previous scheduling strategy, increasing number of threads
leads to significant increase of runtime:
-----------------------------------------------------
Benchmark Time Iterations
-----------------------------------------------------
SchedulerBenchmark/128/1 14.1 ns 49496153
SchedulerBenchmark/128/2 3965 ns 240173
SchedulerBenchmark/128/4 13162 ns 71478
SchedulerBenchmark/128/8 30643 ns 29614
SchedulerBenchmark/128/16 63694 ns 10000
SchedulerBenchmark/256/1 24.1 ns 28943598
SchedulerBenchmark/256/2 3878 ns 227498
SchedulerBenchmark/256/4 13293 ns 69817
SchedulerBenchmark/256/8 31117 ns 32640
SchedulerBenchmark/256/16 59503 ns 14910
SchedulerBenchmark/1024/1 56.7 ns 12048398
SchedulerBenchmark/1024/2 4346 ns 203140
SchedulerBenchmark/1024/4 13487 ns 66736
SchedulerBenchmark/1024/8 30982 ns 33090
SchedulerBenchmark/1024/16 63199 ns 14762
SchedulerBenchmark/4096/1 189 ns 3633540
SchedulerBenchmark/4096/2 5932 ns 131884
SchedulerBenchmark/4096/4 14784 ns 61236
SchedulerBenchmark/4096/8 35857 ns 29276
SchedulerBenchmark/4096/16 63934 ns 10000
With new scheduling strategy, increasing requested number of threads
does not result in that high increase of runtime
-----------------------------------------------------
Benchmark Time Iterations
-----------------------------------------------------
SchedulerBenchmark/128/1 14.1 ns 49323498
SchedulerBenchmark/128/2 2411 ns 362916
SchedulerBenchmark/128/4 3556 ns 243026
SchedulerBenchmark/128/8 4346 ns 200626
SchedulerBenchmark/128/16 5066 ns 169698
SchedulerBenchmark/256/1 24.2 ns 28960018
SchedulerBenchmark/256/2 2330 ns 388470
SchedulerBenchmark/256/4 3864 ns 219233
SchedulerBenchmark/256/8 4399 ns 195225
SchedulerBenchmark/256/16 5111 ns 161858
SchedulerBenchmark/1024/1 55.9 ns 12204777
SchedulerBenchmark/1024/2 2541 ns 329807
SchedulerBenchmark/1024/4 3977 ns 222628
SchedulerBenchmark/1024/8 4607 ns 193548
SchedulerBenchmark/1024/16 5031 ns 160285
SchedulerBenchmark/4096/1 188 ns 3714433
SchedulerBenchmark/4096/2 4203 ns 188284
SchedulerBenchmark/4096/4 4832 ns 171811
SchedulerBenchmark/4096/8 5605 ns 159093
SchedulerBenchmark/4096/16 6425 ns 126861
(both runs were executed on 28-core 56-thread cpu)
Change-Id: I91eca783280598997bfe6abd28019847731692e4
Sameer Agarwal