-
Story
-
Resolution: Done
-
Critical
-
None
-
None
-
2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29
We need to take advantage of multiple CPU's and computer nodes, but we cannot afford to break "incremental score calculation" while we do.
The gain of incremental score calculation is often numberOfEntities/2, so in practice, this gain is much higher than any gain parallelism could bring us.
We need to have both: have our cake and eat it too.
It's a matter of parallelizing the moveScope's.
Do not confuse with Drools multi-threading, which is at a lower level and coming with the new PHREAK algorithm (in 6.x). Due to thread syncs, I suspect that OptaPlanner moveScope parallelization will be more efficient than Drools score calculation parallelization, but it will be nice to have both options
Old Description:
Use Future's to spread all possible moves in each step over a number of threads.
This number of threads is equal to the number of cpu's by default, as no IO is done during solving.
Problems:
- each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated
- a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller.
- Barriers will be needed to collect the result of each step
- decks might be a great way to spread out the load
- blocks
-
PLANNER-137 Planning entity's hashCode() (used by tabu accepter) vs solutionHashCode() (used by solution equality)
- Open
- incorporates
-
PLANNER-1025 Multithreaded solving: queue design for inter-thread communication
- Resolved
- is blocked by
-
PLANNER-1020 Add method Move.rebase(Scoredirector) to allow rebasing moves to other threads
- Resolved
- is incorporated by
-
PLANNER-304 Make OptaPlanner even faster (less slow) and even more scalable
- Resolved
- is related to
-
PLANNER-491 Partitioned Search
- Resolved
-
PLANNER-61 Multi-threaded Benchmarker in Planner
- Resolved
-
PLANNER-83 Planner: new Branch and bound solver, which is a better form of a brute force solver
- Resolved
-
PLANNER-54 Selectors should support cacheType SOLVER with DroolsScoreDirector and IncrementalScoreDirector too: reuse multi-threading id technology to migrate the selector cache to the new solution clone
- Open