I solve a capacitated VRP with time windows and dropped-visit penalties using the routing library (pywrapcp.RoutingModel) with the GUIDED_LOCAL_SEARCH metaheuristic and a wall-clock time_limit. This works correctly.
My problem is throughput / core utilization, not correctness: while a single request is solving, the process pins one CPU core. The other cores sit idle for the whole time_limit. I have verified with htop that a single SolveWithParameters call never rises above ~100% (one core).
Because each request is single-threaded, I cannot make one instance solve faster by adding cores, and a single large request cannot exploit a multi-core machine. (I already run independent requests in parallel and I already split one large problem into geographic clusters that solve concurrently — that helps, but it changes the problem being solved. Here I want to know about one single solve.)
Question
Does the routing solver's local search (GUIDED_LOCAL_SEARCH / SolveWithParameters) ever use more than one thread?
Is there any supported way to make one RoutingModel solve use N cores — e.g. parallel local-search operators, or routing dispatched to the CP-SAT backend with search_parameters.sat_parameters.num_search_workers?
If routing-via-CP-SAT is the intended multi-threaded path, which routing features (disjunctions/penalties for dropped visits, time-window dimensions, per-vehicle arc costs, capacity dimensions) are supported by that backend in 9.12, and is it expected to be competitive with GLS for a ~N-node CVRPTW within a fixed time budget?
OR-Tools version: 9.12.4544 (Python)
--
You received this message because you are subscribed to the Google Groups "or-tools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/or-tools-discuss/c1f16e3b-b842-44ee-8285-1c2750a2dbedn%40googlegroups.com.