anchor.diff:  ** Configure a <<partitionedSearch,Partitioned Search>>.
   * *Multithreaded incremental solving*: solve 1 dataset with multiple threads without sacrificing <<incrementalScoreCalculation, incremental score calculation>>.
   ** Donate a portion of your CPU cores to Planner to scale up the score calculation speed and get the same results in fraction of the time.
  +** Configure <<multithreadedIncrementalSolving,multithreaded incremental solving>>.
   
   image::OptimizationAlgorithms/multiThreadingStrategies.png[align="center"]
   
  
positive.code: is still reproducible, unless the `moveThreadCount` is set to `AUTO` or a function of `availableProcessorCount`.
  ====
  
  The `moveThreadBufferSize` can be used to power tweak the number of moves that are selected but won't be foraged.
  Setting it too low will reduce performance, setting it too high might too.
  Unless you're deeply familiar with the inner workings of multithreaded solving, don't configure this parameter.
  
  To run in an environment that doesn't like arbitrary thread creation,
  
negative.code: </solver>
  ----
  
  A `moveThreadCount` of `4` <<sizingHardwareAndSoftware,saturates almost 5 CPU cores>>:
  the 4 move threads fill up 4 CPU cores completely
  and the solver thread uses most of another CPU core.
  
  The following ``moveThreadCount``s are supported:
  
  * `NONE` (default): Don't run any move threads. Use the single threaded code.
  * ``AUTO``: Let Planner decide how many move threads to run in parallel.
  On machines or containers with little or no CPUs, this falls back to the single threaded code.
  * Static number: The number of move threads to run in parallel.
  +
  [source,xml,options="nowrap"]
  