Tuning questions

[Thomas Sharpless]

OK,  I have a working bundle adjustment that gives good looking answers.  Now I want to make it faster and less chatty.

Currently it runs to the iteration limit (50) reducing the initial error by about as much as could be expected, over 95%.

This takes about 1 minute for 2700 points and 10 minutes for 27000.  The vast majority of that is ascribed to Jacobian evaluation.

This is the debug build; I would expect release code to run faster, especially if there is a lot of object creation and destruction happening.  

My machine has 8 cores and a strong CUDA-capable GPU.  Is there any way ceres could exploit those?

But I'd really like to know if there are ways I could boost the intrinsic convergence rate, and/or make the Jacobian evaluation more efficient.

The solver also prints a tremendous amount of stuff that I don't think I will find useful.  I've tried options minimizer_progress_to_stdout and logging_type but all they do is remove the useful line that shows the bottom line per iteration.  I'd like to keep that and suppress everything else.

Thanks again for all your help.

-- Tom

[Sameer Agarwal]

Debug build should be insanely slow.

Can you share the output of Summary::FullReport once you are working with an optimized build?

Solver::Options::num_linear_solver_threads and Solver::Options::num_threads are your friends, depending on the system and compiler you are on. 

We have no GPU support right now.

I am guessing you are using miniglog, which is why its printing out all that gibberish. There are two solutions.

1. Use real glog.

2. You can define MAX_LOG_LEVEL at compile time and control the level of verbosity. 

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/d124e66e-c2cf-4df5-ae2a-d1b5fa4fc126%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Sweeney]

Also, try enabling c++11 support with Ceres (from the master branch). I have found it can speed things up quite a bit because of the SSE-aligned Jet operations if you are using autodiff.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUCRZx-vo7FouMHDrkmXJtj8QO%2BncDNc0pG-zZCqne5bYA%40mail.gmail.com.

[Thomas Sharpless]

Thanks Sameer, Chris,

I'll certainly try out a release build soon.  Maybe with real glog, though I do like to minimize dependences (of course the whole app has dozens, so what's couple more...) 

And the threading options.  I somehow got the impression that only one algorithm, from Suite Sparse (which I am not using) was actually multithreaded.

Chris, is enabling C++11 a Cmake option? Or something less obvious?

[Chris Sweeney]

Yes, you simply supply -DCXX11=ON to force Ceres to use c++11. But be careful because I think it requires that any applications that use Ceres then require c++11 mode as well. Alex can probably say more on this.

Chris

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/4dde6f13-5657-425b-9375-f007cf685ec3%40googlegroups.com.

[Sameer Agarwal]

Thomas,

The evaluation of jacobians is threaded if you have openmp.

When you are using any of the Schur linear solvers, the eliminator is also threaded. So DENSE_SCHUR, SPARSE_SCHUR, ITERATIVE_SCHUR can all use num_linear_solver_threads.

Sameer

On Thu, Feb 4, 2016 at 2:51 PM Thomas Sharpless <tksha...@gmail.com> wrote:

[Alex Stewart]

Chris is quite right, if you enable CXX11, then all projects using Ceres must also use C++11.  For even relatively recent versions of CMake, this is handled automatically when building a target that uses Ceres (and is built with CMake), otherwise you will have to set this explicitly for client code yourself.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUDPaJFchmhwJui2msT2j4Wt2L2kiwNZoQSLiVK4XHi6yQ%40mail.gmail.com.

[Thomas Sharpless]

Please, what specifically to I have to do to "enable CXX11" (using cmake on Windows; want to build both with msvc12 and gcc5).

--
You received this message because you are subscribed to a topic in the Google Groups "Ceres Solver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ceres-solver/skL6salRf5I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/59E2F6F8-AF09-420B-A8D6-21CEB71B9E09%40gmail.com.

[Thomas Sharpless]

From cmakelists.txt:

if (NOT WIN32) # Ceres does not use C++11 internally, however it does use shared_ptr # (required) and unordered_map (if available), both of which were present in # previous iterations of what became C++11. GCC & Clang can have both TR1 & # C++11 versions of both shared_ptr & unordered_map and by default on Linux, # we will detect the TR1 versions if they exist, as they do NOT require # -std=c++11 to be passed when compiling Ceres, and any client code that uses # Ceres. This will result in conflicts if the client code uses C++11. # Enabling this option forces the use of the C++11 versions (& -std=c++11) if # available. # # This option is not available on Windows, as there, any new (C++11 etc) # features available are on by default and there is no analogue to -std=c++11. option(CXX11 "Enable use of C++11 headers if available (requires client code use C++11)." OFF) endif(NOT WIN32) So how does one get shared_ptr under MINGW_W64?

[Alex Stewart]

Thomas,

The logic for the CXX11 option is covered here: http://ceres-solver.org/building.html#options-controlling-ceres-configuration

1) On MSVC, the option is not available, as any new features are enabled by default.  There is no need for an option, as it would always be enabled, and in fact could not be disabled.

2) The situation for MinGW-w64 / CygWin is different.  Depending upon the CMake version, WIN32 may, or may not, be defined for CygWin, it should however (I think) be defined for MinGW.  As such, the most likely outcome is that the CXX11 option would not currently be available for either MinGW or CygWin.  As they will both present as GCC, the detection logic will still work, but you will get the pre-C++11 (TR1 likely) versions.  The good news is that this means code using Ceres would not need to use C++11 either; the bad news is that it *couldn’t* do so.

As this option should only really be absent on MSVC, please try this CL:

https://ceres-solver-review.googlesource.com/#/c/7321/

which should fix this, and make the CXX11 option available on MinGW & CygWin whilst still disabling it for MSVC.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAEzyns0AcU7b30SSFbLzLw_7NmqukcOQ3yJzUsrxRxpFNVkbvw%40mail.gmail.com.

[Thomas Sharpless]

OK, as predicted, a release dll build of ceres solves my problem a LOT faster: 50 iterations in 3.3 seconds vs 1 minute for 2700 points, 10.8 seconds vs 10 minutes for 27,000 points, single threaded.  Since it is built with MSVC2013 it does have shared_ptr & should be capable of using multiple cores as well. Unfortunately I can't use this dll with a debug build of my app due to the usual Windows runtime library incompatibilities; so for debugging I'll just solve a subset.  Here is the summary for 27K points:

Solver Summary (v 1.12.0-eigen-(3.2.5)-lapack-eigensparse-openmp)

                                     Original                  Reduced

Parameter blocks                        26688                    26688

Parameters                              26693                    26693

Residual blocks                         27106                    27106

Residual                                27106                    27106

Minimizer                        TRUST_REGION

Dense linear algebra library            EIGEN

Trust region strategy     LEVENBERG_MARQUARDT

                                        Given                     Used

Linear solver                     DENSE_SCHUR              DENSE_SCHUR

Threads                                     1                        1

Linear solver threads                       1                        1

Linear solver ordering              AUTOMATIC                 26687, 1

Cost:

Initial                         6.717940e-001

Final                           3.802643e-002

Change                          6.337676e-001

Minimizer iterations                       50

Successful steps                           50

Unsuccessful steps                          0

Line search steps                          61

Time (in seconds):

Preprocessor                           0.1656

  Residual evaluation                  0.4081

    Line search cost evaluation        0.0000

  Jacobian evaluation                  4.8755

    Line search gradient evaluation    3.3519

  Linear solver                        3.6430

  Line search polynomial minimization  1.0884

Minimizer                             10.5980

Postprocessor                          0.0017

Total                                 10.7654

Termination:                   NO_CONVERGENCE (Maximum number of iterations reached.)

On Thursday, February 4, 2016 at 10:46:24 AM UTC-5, Thomas Sharpless wrote:

[Sameer Agarwal]

Thomas,

The proportion of these numbers look sane to me.

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/9283baa9-8059-407c-892d-b51f4a497e6d%40googlegroups.com.