Closed HeuristicLab-Trac-Bot closed 13 years ago
Stored execution contexts locally for each thread in r5183.
Adapted
DebugEngine
according to cancellation changes in r5188.
Deleted branch in r5194 (not migrated).
Adapted EAs to enable parallel solution evaluation in r5208.
epitzer reviewed and agreed with changes of
DebugEngine
in r5193.
Adapted distance matrix calculation in
TSPCoordinatesPathEvaluator
in r5210 to avoid that multiple distance matrices are created, if the evaluator is executed in parallel.
When using GP to solve a symbolic regression or symbolic classification problem with the
ParallelEngine
, an exception is thrown. It seems that there are still some synchronization issues in the corresponding evaluators.
Made
SimpleArithmeticExpressionInterpreter
thread safe with r5223.
Please update GP symbolic regression and symbolic classification samples.
Comments regarding r5208
- OSGA: EvaluatedSolutions should probably not be incremented in each thread by one, but after the parallel region and by the size of SelectedParents. The IntCounter is implemented thread-safe, but it will probably cause a lot of waits. In the case of reevaluating the mutated individuals after the OS, I think it would be okay to do it inside, though of course it would be nicer to just increment by the number of subscopes.
- I'm hesitating to accept the change to
IntCounter
making it thread-safe. I would like to spark a discussion on providing additional thread-safe variants for basic operators. We could introduce a new plugin HeuristicLab.Operators.(ThreadSafe|Parallel). That way the operator designer doesn't need to make the trade-off, but instead the algorithm designer has to make the decision (which she has to make anyway). It's also more obvious if an operator is thread-safe or not. On the other hand the library is already quite complex and it doesn't get simpler if we add more operators.Regarding r5210
- I'm fine with that, although I'm swinging in favor of removing the feature from the evaluators and putting it into the problem. What was the reason again that we didn't do this?
TODO for me:
Remove counting of evaluated solutions from the parallel part
OSGASASEGASAIsland OSGAIsland GAGAESNSGA-IIAdd an operator that counts the sub-scopes and increments EvaluatedSolutions accordingly after the parallel part- ~~Allow parallel evaluation in ~~
LocalSearchSimulatedAnnealing(note: does not work)TabuSearch
- Removed changes to
IntCounter
that would make it thread-safe, if a thread-safe operator is needed a separate one should be implemented- Moved counting of evaluated solutions out of the parallel region
- Adapted local search to perform move evaluation in parallel (using the parallel engine)
- Adapated Tabu Search to run move evaluations and tabu check in parallel
Note that simulated annealing can't be parallelized easily. It will apply any move as soon as it satisfies the acceptance criterion.
Issue migrated from trac ticket # 1333
milestone: HeuristicLab 3.3.3 | component: ParallelEngine | priority: high | resolution: done
2010-12-11 22:52:26: @s-wagner created the issue