Conversation
| (; termination_reltol, time_limit, max_kkt_passes) = params | ||
| if batched_all(<=(termination_reltol), relative!!(dest, err)) | ||
| return OPTIMAL | ||
| st = if batched_all(<=(termination_reltol), relative!!(dest, err)) |
There was a problem hiding this comment.
Unrelated? I personally don't like var = if ... that much, but maybe that's just me
There was a problem hiding this comment.
Yeah, unrelated. But when I tried to trace the whole loop instead of just the step!, I had issues with if/else statements like this one which return a non-traceable struct
| Return the number of integer variables in `milp`. | ||
| """ | ||
| nbvar_int(milp::MILP) = sum(milp.int_var) | ||
| nbvar_int(milp::MILP) = sum(identity, milp.int_var) |
There was a problem hiding this comment.
Why? Is this a Reactant bug?
There was a problem hiding this comment.
I think this errors inside Reactant because the integers are traced and so they have no concrete value. It's only used inside printing routines though so not essential
| algo = PDHG( | ||
| Float32, | ||
| Int32, | ||
| Matrix; |
There was a problem hiding this comment.
Ah, you're using a dense matrix! I have been taking a bit with the Reactant people how we could maybe have some basic sparse support. There is https://mlir.llvm.org/docs/Dialects/SparseTensorOps/, but we would need to lower it into cuSPARSE calls ourselves
There was a problem hiding this comment.
Put up EnzymeAD/Reactant.jl#3198, which should enable spmv and spmm support in Reactant
|
Apparently we can avoid the worse compilation with |
2 participants
Right now, Reactant is slower than it should be because we keep XLA from donating any buffers. Open a Reactant issue with the MWE