- In light of the C++11 threads threading option this is no longer
necessary for cross-platform threading support and did not offer a
noticeable performance gain over either the C++11 threads
implementation or OpenMP.
Change-Id: Icb588d520888c19a1775171795b55bcaffb3d256
This was currently buried in port.h. Since there is exactly one use
of the max_align_t handling, it is better from a readability
and cleanliness perspective to have this in jet.h.
Change-Id: I2f3dde75df7c333bd95393b9e4fc4cd5160d6afb
Fixes a bug introduced in 12280 that incorrectly used xor for multiple
values.
Tested it manually by verifying it would fail for 2, 3, or 4 of them
defined.
Change-Id: I90c2662f4744aceaf0119dbbe072beced3f67c9a
Implements ParallelFor using the C++11 based ThreadPool. The C++11
parallel for is 50-70% faster than single threaded, and 20-30% slower
than TBB.
Tested by compiling with OpenMP, TBB, and C++11 Threading support and
ran the unit tests. Ran bazel as well.
Change-Id: I7fd6c9037ff9f200ce6999b5f39918995bb6b8ea
- Eigen versions < 3.3 only supported SIMD instructions that required
16-byte alignment (SSE), whereas Eigen >= 3.3 also supports AVX
instructions which require 32+-byte alignment.
- Previously we only ever requested 16-byte alignment for Jets (if >=
C++11 was enabled) which resulted in Eigen assertions being triggered
on some compilers as reported as Issue #251:
https://github.com/ceres-solver/ceres-solver/issues/251.
- Now we use Eigen’s EIGEN_MAX_ALIGN_BYTES macro, defined in Eigen >=
3.3 to specify the byte alignment for Jets when C++11 is enabled for
Eigen >= 3.3. For Eigen versions < 3.3, we maintain the previous
behaviour of 16.
Change-Id: I749af7a70ae794e0c2a59301128db781e338422c
- As per Andrew Hunter’s comments in the commit which added Jet
alignment when using C++11 here:
https://ceres-solver-review.googlesource.com/#/c/7100, there is wide
lattitude in the standard about what the maximum supported alignment
can be.
- Previously, we were forcing the alignment to 1, if the value of
alignof(std::max_align_t), which we use as a proxy for the maximum
supported alignment on the platform, was < 16.
- An alignment of 1 is not valid for Jets, as it would weaken the
natural alignment of the types within a Jet, which would typically be
4 (32-bit systems) or 8 (64-bit systems), thus resulting in a compiler
error.
- This was reported as issue 235 for Clang 3.8 on i386:
https://github.com/ceres-solver/ceres-solver/issues/235.
Change-Id: Ie39e5499c64f9231f29ebf4392992b5c9ce2e385
I169b637a1e2a106956b536c41d6a514a266e7cc0 marked Jets (in C++11) as
aligned to 16 bytes, and enabled Eigen vectorization. However, to
implement this, we added Eigen includes to port.h.
Turns out this broke some other tricks Ceres uses (redefining Eigen
constants for better performance), so we don't want to do that. Move
most of the implementation to jet.h where it is safe.
Change-Id: I47c6fc4180db1ff674bc660723dd5a2b84254e0d
We currently don't align the infinitesimal part of a Jet to a 16-byte
boundary (and thus force Eigen to avoid using SSE ops)--as a member of a
larger struct, we couldn't guarantee Jets would be allocated on
appropriately-aligned boundaries. However, C++11 adds better support
for requesting alignment: we can use it to guarantee the members will be
properly aligned, and tell Eigen to vectorize.
There is a significant gotcha here: the standard gives wide latitude to
implementations as to which alignments they choose to support. If we
ask for 16 and the system only supports 8, we may have misaligned
Jets. So we test (using alignof(std::max_align_t)) that the current
system supports 16-byte aligned values; if not, we fall back to the
current solution.
Two other small notes:
- This is obviously gated on C++11 support, and
thus we put the logic in port.h and export some useful #defines.
- GCC 4.8.x has a
bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019) that has
max_align_t in the wrong namespace. This will not be a problem with a
modern GCC, but add a small workaround since many systems still ship 4.8.
This results (on a x86 workstation) in a 60% speedup in Jacobian
evaluation on bin/simple_bundle_adjuster problem-16-22106-pre.txt.
Change-Id: I169b637a1e2a106956b536c41d6a514a266e7cc0
Since Ceres is moving to using GitHub for issues, and the Google
Code URL in the current copyright header will soon become invalid,
update all the headers.
Change-Id: I1fce70375d1bcf098591f07b4d8f01a5c1e0789c
For historical reasons we had a "using namespace std;" in port.h. This
is generally a bad idea. So removing it and along the way doing a bunch
of cpplint cleanup.
Change-Id: Ia125601a55ae62695e247fb0250df4c6f86c46c6
- Previously we passed all compile options to Ceres via add_definitions
in CMake. This was fine for private definitions (used only by Ceres)
but required additional work for public definitions to ensure they
were correctly propagated to clients via CMake using
target_compile_definitions() (>= 2.8.11) or add_definitions().
- A drawback to these approaches is that they did not work for chained
dependencies on Ceres, as in if in the users project B <- A <- Ceres,
then although the required Ceres public compile definitions would
be used when compiling A, they would not be propagated to B.
- This patch replaces the addition of compile definitions via
add_definitions() with an autogenerated config.h header which
is installed with Ceres and defines all of the enabled Ceres compile
options.
- This removes the need for the user to propagate any compile
definitions in their projects, and additionally allows post-install
inspect of the options with which Ceres was compiled.
Change-Id: Idbdb6abdad0eb31e7540370e301afe87a07f2260
This compiler defines shared_ptr in std::tr1 namespace, but
for this <tr1/memory> is to be included. Further, this compiler
also does have <memory> header which confused previous shared
pointer check.
Simplified logic around defines now, so currently we've got:
- CERES_TR1_MEMORY_HEADER defined if <tr1/memory> is to be
used for shared_ptr, otherwise <memory> is to be used.
- CERES_TR1_SHARED_PTR defined if shared_ptr is defined in
std::tr1 namespace, otherwise it's defined in std namespace.
All the shared_ptr checks are now moved to own file FindSharedPtr
which simplifies main CMakeLists.
Change-Id: I558a74793baaa0bd088801910a356be4ef17c31b
Fix variable names in port.h and fix fpclassify when
using gnustl. This was tested by switching to gnustl
in the JNI build.
Thanks to Carlos Hernandez for suggesting the gnustl fixes.
Change-Id: I690b73caf495ccc79061f45288e416da1604cc72
By default shared_ptr is now assumed to be
in the standard <memory> header and in the
std namespace.
Previously the way the ifdefs were structured if the appropriate
variable was not defined, it would default to <t1/memory>.
The new defaults are more future proof.
Change-Id: If457806191196be2b6425b8289ea7a3488a27445
Solver::Options::linear_solver_ordering and
Solver::Options::inner_iteration_ordering
were bare pointers even though Solver::Options took ownership of these
objects.
This lead to buggy user code and the inability to copy Solver::Options
objects around.
With this change, these naked pointers have been replaced by a
shared_ptr object which will managed the lifetime of these objects. This
also leads to simplification of the lifetime handling of these objects
inside the solver.
The Android.mk and Application.mk files have also been updated
to use a newer NDK revision which ships with LLVM's libc++.
Change-Id: I25161fb3ddf737be0b3e5dfd8e7a0039b22548cd
This is a workaround for anyone building Ceres in an environment
where there is a non-standard string implementation in the global
namespace. Due to the way the standard is written, a "using
namespace X" import is not high enough precedence to resolve a
naked reference to "string". Instead, by explicitly importing
string, the lookup becomes unambiguous.
Change-Id: I8d70463de01c482796c5bc09da05b37d21e7af96
Alex Stewart