Optimize the sequential solver

[jmitchell]

The existing sequential implementation should be optimized.

Issue #3 considers ways to optimize the search through concurrency, thereby adding the ability to parallelize and distribute work. Regardless of the solution arrived at there, some processes will be doing sequential work. Sequential optimizations will benefit the whole system.

Currently the Sudoku example runs in about 5 seconds on my test VM, but there are several changes that could make it go faster.

• refactoring
• algorithm improvements (e.g. backjumping)
• @compile hints
• macros
• protocol consolidation
• VM configuration options
• NIFs (see also: Rustler)
• OpenCL or other black-box parallelization solutions

There are many approaches. To weigh the trade offs of all of them it would help to implement several provisional Backtrex.Experimental.solve_* entry points and set up benchmarks across all of them. The benchmarks should exercise multiple examples (see #5) and identify bottlenecks both in the solver implementations and the example's callbacks.

[jmitchell]

Finish #12 (Generate profiling reports) first.