Parameter performance, could named Constants be supported?

[pgkirsch]

Hi all,

I have a question that I would typically ask Steven but given that he is on paternity leave I figured I'll ask here instead.

I've recently vectorized one of our problems (not enormous but ~1000's of constraints pre-vectorization) and in an attempt to make the new version of the problem clean and readable (i.e. easier to debug) I used a Parameter for each of the matrices. The issue now is that even simple unit tests cause our continuous integration pods to crash because solving takes so long. The solution is obviously to set ignore_dpp=True but doing that for every unit test feels like a clumsy remedy just to be able to have Parameters. Maybe Parameters isn't what I want because I'm not actually looking to change values -- I just want to be able to write readable vectorized optimization problems but it doesn't seem to be possible to name Constants. Would the cvxpy developers consider supporting named Constants? Or is there some other solution I'm not thinking of?

Thanks!

Philippe

[SteveDiamond]

Hi Philippe! Could you try timing the optimization with the CPP and SciPy different backends?
https://www.cvxpy.org/tutorial/advanced/index.html#canonicalization-backends

Could you format the results with the info:
Number of parameters | compilation time with CPP backend | compilation time with SciPy backend | compilation time with CPP backend and ignore_dpp=True

Named constants would be reasonable but if the SciPy backend is fast enough it might make sense to add logic to trigger it automatically when there are enough parameters. It was designed to be much faster with parameters than the CPP backend. @phschiele what do you think?

[pgkirsch]

Haha hey Steven, my feeble effort to shield you from work questions was clearly not successful.

I tried running all three versions as requested but almost 2 hours into it and it's still running for both of the don't-ignore-dpp cases. Maybe surprisingly the SCIPY_CANON_BACKED took even longer to perform ConeMatrixStuffing, I'm not sure why, but both are still stuck in applying the MOSEK reduction.

	CPP + ignore_dpp=True	CPP	SciPy
Compilation time	0.8 s	> 2 hours	> 2 hours
ConeMatrixStuffingTime	<< 1 s	10 mins	49 mins

The problem has 5 cvxpy Parameters (825491 scalar parameters). Only one of these parameters is the problem because it's an 857x959 sparse matrix with 959 elements. The other parameters are ~900 element vectors.

Attached the full verbose output for the solution with ignore_dpp=True.
solution_with_ignore_dpp.txt

[SteveDiamond]

OK, thanks for sharing that info! It looks like named constants are the way to go.

[pgkirsch]

Ok thanks! Obviously not urgent, it's a nice-to-have. In the meantime ignore_dpp works well and I can also easily just hold off on making that one matrix into a parameter.

[SteveDiamond]

One approach would be to create a NamedConstant subclass of cvxpy.Constant. If you override the __init__ to add a name field and then override the name function to print the name that should work.

[phschiele]

Cross referencing: Named constant have been added here:
#2335

[rileyjmurray]

My 2 cents: I support the idea of named Constants.

…

On Sat, Jan 13, 2024 at 11:54 AM Steven Diamond ***@***.***> wrote: Hi Philippe! Could you try timing the optimization with the CPP and SciPy different backends? https://www.cvxpy.org/tutorial/advanced/index.html#canonicalization-backends Could you format the results with the info: Number of parameters | compilation time with CPP backend | compilation time with SciPy backend Named constants would be reasonable but if the SciPy backend is fast enough it might make sense to add logic to trigger it automatically when there are enough parameters. It was designed to be much faster with parameters than the CPP backend. @phschiele <https://github.com/phschiele> what do you think? — Reply to this email directly, view it on GitHub <#2322 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACRLIFBL5XM7FPFY33OSIR3YOK34RAVCNFSM6AAAAABBZCWIIKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCMJZGA4TS> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>