I have recently started laying the ground work for multi-threaded solving, but it will probably only be completed by 6.1 (Q3 2013). https://issues.jboss.org/browse/JBRULES-681 The whole difficulty is going parallel without breaking "incremental score calculation (delta's)". The scalability gain of delta's is bigger than parallelization. Combining the 2 will be a major step forward. That being said, your approach seems to be at a much higher level: - Some of those ways might work (although the gain might be low) - Other approaches, such as partitioning [1] a single solution into smaller parts per threads, are doomed to fail due to the nature of NP-complete problems. [1] For example: you can't take the cloud balancing problem of 300 processes and 100 computers and have 10 threads optimally assign 30 processes to 10 computers and expect to find a global optimal solution. Further more, once you have serious constraints (such as machinereassignment's constraint "processes of the same service should run on computers on distinct locations"), you can't even optimize 30 processes without knowing how the other 270 processes are assigned. Op 19-12-12 03:31, 软件0907黄泓 schreef:

Op 02-04-13 17:11, roman.stumm schreef: 6.0 should be a lot faster with chained planning variables, I remember fixing several performance/scalability issues there. (at least if you use the normal moveSelectors IIRC) Try 6.0.0.Alpha9 or 6.0.0.Beta1 when its released (later this week hopefully). How many stops do you want to scale too? If it really big, like the Santa problem, where we faced 150 000 stops, some extra tricks might be needed. After 6.0 is out, I am going to hide in a cave and come out when the Solver is multi-threaded with delta's :) (metaphorically speaking) https://issues.jboss.org/browse/PLANNER-76 Mult-threading without delta's is relatively easy but much slower than the current implementation. Multi-threading with delta's is uncharted territory. I believe it's possible, time will tell.. This is called partitioning. It's an often used technique, that works, but not as well as a solver that can scale out. Try upgrading to 6.0 first. Let us know how that works out. Partitioning implies Use <subChainChangeMoveSelector> <subChainSelector> <maximumSubChainSize>20</>... similar for subChainSwapMoveSelector. See VRP in 6.0. I 'll improve the docs for these special moves by 6.0.0.Final.