Commit Graph

9 Commits

Author SHA1 Message Date
Sameer Agarwal 42a84b87fa Expand reporting of timing information.
1. Add an ExecutionSummary object to record execution
   information about Ceres objects.
2. Add an EventLogger object to log events in a function call.
3. Add a ScopedExecutionTimer object to log times in ExecutionSummary.
4. Instrument ProgramEvaluator and all the linear solvers
   to report their timing statistics.
5. Connect the timing statistics to Summary::FullReport.
6. Add high precision timer on unix systems using
   gettimeofday() call.
7. Various minor clean ups all around.

Change-Id: I5e09804b730b09535484124be7dbc1c58eccd1d4
2013-02-06 01:00:38 -08:00
Sameer Agarwal 71c8058478 Remove ExecutionSummary from Evaluator and LinearSolver
Change-Id: If4dbaf516a8b14e0a79e1a2116ce66a99ed4a592
2013-01-31 17:33:01 -08:00
Sameer Agarwal bdd87c03ed Add an ExecutionSummary object that the Evaluator and LinearSolver can use to
report execution statistics of all kinds.

Currently a single map which maps arbitrary strings to doubles is supported,
which allows for precise timing information to be communicated.

Change-Id: Ibd930aca5c9e6cae89bcfeffe9b13e2887644881
2013-01-29 16:24:31 -08:00
Sameer Agarwal 0c52f1e29b LinearSolver::Options::num_eliminate_blocks is dead.
Replaced with LinearSolver::Options::elimination_groups.

Change-Id: I7c07542ec19279a35ddf6da498d417a79395c77f
2012-09-17 11:40:03 -07:00
Sameer Agarwal 7a3c43b847 Block oriented fill reducing orderings.
By virtue of the modeling layer in Ceres being block oriented,
all the matrices used by Ceres are also block oriented.
When doing sparse direct factorization of these matrices, the
fill-reducing ordering algorithms can either be run on the
block or the scalar form of these matrices. Running it on the
block form exposes more of the super-nodal structure of the
matrix to the Cholesky factorization routines. This leads to
substantial gains in factorization performance.

This changelist adds support for approximate minimium degree
orderings to be computed on the block structure of the
Schur complement matrix. This affects, SchurComplementSolver
and VisibilityBasedPreconditioner and SparseNormalCholesky
 when using SuiteSparse.

A bool, use_block_amd has been added to Solver::Options and
bundle_adjuster.cc has been updated to allow testing with it.

When combined with a multithreaded Schur elimination, speed ups
can be seen quite uniformly across the board. For some problems
this can be dramatic, reducing the factorization time from 70
seconds down to 17 seconds.

Change-Id: I15ebb0afcbc85ada032ec8d179ee3a2f7c8d3e46
2012-06-06 22:02:17 -07:00
Sameer Agarwal b051873a55 Multiple sparse linear algebra backends.
1. Added support for CXSparse - SparseNormalCholesky and
   SchurComplementSolver support SuiteSparse and CXSparse now.
   I am not sure I will add suport for visibility based
   preconditioning using CXSparse. Its not a high priority.

2. New enum SparseLinearAlgebraLibraryType which allows the user
   to indicate which sparse linear algebra library should be used.

3. Updated tests for SolverImpl and system_test.

4. Build system changes to automatically detect CXSparse and
   link to it by default -- just like SuiteSparse.

5. Minor bug fixes dealing in the cmake files and VBP.

6. Changed the order of the system test.

7. Deduped the unsymmetric linear solver test.

Change-Id: I33252a103c87b722ecb7ed7b5f0ae7fd91249244
2012-05-29 19:44:43 -07:00
Sameer Agarwal a9d8ef847f 1. Remove constant_sparsity from LinearSolver::Options. It introduces
unnecessarily complexity in the structure of linear solvers and preconditioners.
This is the first step towards cleaning up the Preconditioner interface.

2. Minor tweaks and cleanups to the various linear solvers.
2012-05-14 02:28:05 -07:00
Keir Mierle f7898fba1b Add a general sparse iterative solver: CGNR
This adds a new LinearOperator which implements symmetric
products of a matrix, and a new CGNR solver to leverage
CG to directly solve the normal equations. This also
includes a block diagonal preconditioner. In experiments
on problem-16, the non-preconditioned version is about
1/5 the speed of SPARSE_SCHUR, and the preconditioned
version using block cholesky is about 20% slower than
SPARSE_SCHUR.
2012-05-05 20:55:08 -07:00
Keir Mierle 8ebb073038 Initial commit of Ceres Solver. 2012-04-30 23:09:08 -07:00