Why IPM instead of PDLP for the on-GPU LP solver?

[Lhongpei]

Hi team, thanks for open-sourcing LPLB!
In the README you mention that the embedded LP solver is a single-SM Interior-Point Method (IPM) built on cuSolverDx/cuBLASDx.
Could you briefly share the design rationale for choosing IPM over a first-order method such as PDLP (or another primal-dual hybrid gradient variant)?

[Elevator14B]

The simple reason is that IPM was the only algorithm I felt confident implementing myself. Given the hard constraint of avoiding CPU-GPU communication, I went with this basic, self-contained IPM implementation, and it turned out to be reasonably effective.

I'm always keen to learn more about advanced solver designs though — any pointers or resources you'd recommend would be most welcome!

[Lhongpei]

Thanks for the honest response!

Regarding the workload, could you share the typical scale (number of rows, columns and non-zeros) of the LP problems you usually solve with this implementation?

[Elevator14B]

See here:

constexpr int NC = GROUP_SIZE + GROUP_SIZE * DUP_PER_RANK;
constexpr int NV = GROUP_SIZE * DUP_PER_RANK * 2 + GROUP_SIZE + 2;

NC is number of constraints and NV is number of variables.

For the cube-8p in-node balancing strategy, GROUP_SIZE = 8 and DUP_PER_RANK = 2, so NC = 24 and NV = 42. Other strategies may give a bit larger shape, but all quite small.