exact VS osqp

Version 1.0.0 of Exact is released.

>> The workload is memory bound not compute bound.

> I don't think so? How many gigabytes per second per core are you processing?

That's what the Intel VTune profiler tells me. 39.2% Memory bound = 21,7% of clock ticks L1 bound (execution stalled for data that was in L1) + 12.4% L3 bound on a Haswell 4 core Xeon.

> If for some reason you can talk about this problem to random SIMD programmers online privately but you cannot post about this problem publicly

I can talk about it publicly. I just did not want to distracted from the actual hardware question. I recently started to contribute to this https://gitlab.com/JoD/exact open source project. The algorithm tries to find a valid assignment for a bunch of equations of this form 4x1 -3x57 +1* not(x1232) <= 4 (there are special cases already accelerated). We guess an assignment for a certain variable, check all constraints, sometimes constraints imply other assignments to other variables (if x1 is true and x1232 is false x57 has to be true) then those get propagated to. One technique is called watch propagation and can be done for the SAT family of clauses. This technique is in incompatible with branching along assignments. I find SIMD over clauses dubious, as they are mostly random accessed of different length and sparse. The embarrassing parallelization comes from being able to work one different parts of the parameter space and exchange clauses learned from conflicts. We are currently not doing that yet but plan to do something HordeSAT like over MPI (there is different slightly cleverer tree exchange variant over MPI all to all but i do not have that reference handy).

We have some horrible sins (such a virtual method table look ups in loops, no -march=native compiler flags in main branch, ...) which the main developer created and we have not cleaned up. If i could nerd snipe you to run some experiments with that codebase and contribute some SIMD loops (with -march=native -mtune=native only 4 functions are currently SIMD, none are significant to the performance) that be great. For all the divisibilty checking i currently plan this: https://www.reddit.com/r/exact/comments/wokfhl/resource_on_f... (we spend 3% of compute time in the standard libraries modulo)

I use JuMP as modeling language. For MILP i am usually using Gurobi or SCIP. For ILP problems have have been looking in to the exact solver https://gitlab.com/JoD/exact which seems quiet promising.

For NLP i usually go with either https://worhp.de/ or just IpOpt.

There's also two bindings for the osqp library (which is written in C), osqp published 2 years ago and osqp-rust published 3 months ago. I don't know what are the differences between them, but they both target osqp 0.6.2 (released in 2021) while the last released version is osqp 0.6.3 which was released last week.

Cvxpy is overkill for a standard quadratic program. I’d recommend trying OSQP https://osqp.org which can take advantage of sparsity.

I have been using OSQP [1] quite a bit in a project where I needed to solve many quadratic programs (QPs). When I started the project, OSQP didn't exist yet; I ended up using both cvxopt and MOSEK; both were frustratingly slow.

After I picked up the project again a year later, I stumbled across the then new OSQP. OSQP blew both cvxopt and MOSEK out of the water (up to 10 times faster) in terms of speed and quality of the solutions. Plus the C interface was quite easy to use and super easy (as far as numerics C code goes) to integrate into my larger project.

[1] https://osqp.org/

For quadratic programming—which is a class of problems in convex optimization, which is a sub-field of numerical optimization in general—a solver that is frequently used is OSQP. Although it is implemented in C++ you can also use it in Python thanks to its bindings. If your goal is to use a solver that's state-of-the-art and relatively versatile it is a good pick. If your goal is to find the best solver for a given problem, then there is no one-stop-shop. For example in this benchmark OSQP was the best-performing solver for sparse problems but quadprog performed better on dense problems.