Setting number of cores in PDLP

[constantinosTsirogiannis]

Hi all,

Thanks a lot for the magnificent work in developing the latest version of PDLP. On the latest paper that you have uploaded on arxiv regarding PDLP, you mention that the new method supports multithreading.

I have tried to look in the documentation and the forum to see if there is any way that I can set the preferred number of threads for PDLP. However, I could not find something except some parameter setting for the CP_SAT solver. Therefore, could you provide a minimal example on how to set the number of cores used by PDLP (specifically for python and C++)?

Thanks in advance and keep up the excellent work,

--Constantinos

[sschnug]

That probably depends on A: what interface and B: what version you are using.

Using the math-opt interface it should work like any other solver parameters.proto

edit Above proto-message also has an PDLP-specific param-field and there is even a python-example using it to set threds: https://github.com/google/or-tools/blob/v9.12/ortools/pdlp/samples/simple_pdlp_program.py#L62

    params = solvers_pb2.PrimalDualHybridGradientParams()
    # Below are some common parameters to modify. Here, we just re-assign the
    # defaults.
    optimality_criteria = params.termination_criteria.simple_optimality_criteria
    optimality_criteria.eps_optimal_relative = 1.0e-6
    optimality_criteria.eps_optimal_absolute = 1.0e-6
    params.termination_criteria.time_sec_limit = np.inf
    params.num_threads = 1

Using the low-level interface (i don't think many people use it), i used the following in the past:

  PrimalDualHybridGradientParams params;
  params.set_num_threads(2);
  auto solution = PrimalDualHybridGradient(qp, params);

I mentioned the version as there are some heavy changes to math-opt happening for quite some time now.

[constantinosTsirogiannis]

Hi,

Thanks for the very quick reply. The version I am using is 9.11.4210 . The interface is the following one (that is the easiest I could find for importing mps files in python):

---

from ortools.linear_solver.python import model_builder

model = model_builder.ModelBuilder()
model.import_from_mps_file(lpPath)

solver = model_builder.ModelSolver('PDLP')
statusLatest = solver.solve(model)

---

Let me know how can I set the number of cores in this context. Thanks again for the help.

[sschnug]

Parameter Options: PrimalDualHybridGradientParams

from ortools.linear_solver.python import model_builder

model = model_builder.ModelBuilder()
model.import_from_mps_file("bla.mps")

solver = model_builder.ModelSolver('PDLP')

solver.set_solver_specific_parameters("verbosity_level:4")
solver.set_solver_specific_parameters("num_threads:16")

statusLatest = solver.solve(model)

->

X@Y:~/Tmp/pdlp_threads$ python3 bla.py 
WARNING: Reducing num_threads from 16 to 8 because additional threads would be useless.
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
W0000 00:00:1740410348.507657   72090 sharded_quadratic_program.cc:62] The transposed constraint matrix has 5 non-zeros in its 0th column. For best parallelization all rows and columns should have at most order 3 non-zeros. Consider rewriting the QP to split the corresponding variable or constraint.

Remarks:

• My .mps file is a toy-problem and PDLP is less robust than simplex- and IPMs on toy-problems (warnings!)
• This API is probably deprecated
• I had to tune num_shards too when i evaluated PDLP 1-2 years ago
  • But my problems were > 2GB which explains why i did use the low-lvl non-proto interface directly

[constantinosTsirogiannis]

Thanks! That is exactly what I wanted.

The thing that puzzles me now is if the interface that I am using invokes some older/slower version of PDLP. When I run with this interface, switching to GLOP works 10-100 times faster than with PDLP, even when PDLP works with extra threads. That makes me wonder if I am using the right version of the library after all. Any thoughts on what could cause this slow behaviour?

[sschnug]

There is a reason simplex- and interior-point based methods are the default. First-order methods are imho quite niche currently and i don't expect the average solver-user to stumble upon instances where PDLP magically dominates everything, except for one case: large-scale (! remember my > 2GB model size example) where simplex doesn't scale (too many iterations) and IPMs need too much memory.

I (no or-tools dev) would not expect too much difference in-between version in regards to PDLP, but PDLP will be less robust and evaluation is therefore not that easy. Even things like termination-criteria are often to be tuned.

Make sure to read https://developers.google.com/optimization/lp/lp_advanced.

One more remark: using presolve with PDLP (basically always on with GLOP) might be important but i don't know if it's not on by default and with large-scale instances presolve won't scale anymore too.

[constantinosTsirogiannis]

I see what you are saying. After performing a few experiments since yesterday, I can see that pdlp on multicore is still quite slow even for LP instances of a million non-zeros or so. I guess all these enthusiastic reactions have to do only with the GPU-based version of this code.