Use inplace when building the NLP model #188
Comments
@amontoison your opinion on top priority for a better NLP (performance improvement) between (i) passing the sparse structure and (ii) going fully inplace? |
In-place (ii) is very important because memory allocations are expensive and you will also remove some allocations in the AD part so you will have a speed-up in different part of the code. (i) is just a one-shot gain speed-up at the creation of your NLP model. You can work on both but the priority is higher on (ii). |
👍🏽 thanks for the insight. priority on (ii), then. |
|
@jbcaillau For the record: julia> foo!(y, x) = begin
y[:] .= x
return
end
foo! (generic function with 1 method)
julia> y = [0]; foo!(y, 3); y
1-element Vector{Int64}:
3
julia> y = [0]; foo!(y, [3]); y
1-element Vector{Int64}:
3 |
|
Related issue: control-toolbox/CTBase.jl#232 |
|
@PierreMartinon PR merged control-toolbox/CTBase.jl#271 up to you 🤞🏾! |
Need a new release. Y must be updated. |
✅ @PierreMartinon you can use CTBase.jl v0.14.0 |
|
ok, thanks ! |
|
@PierreMartinon attaching allocation sizes with the current out of place code on the benchmark created by @0Yassine0 control-toolbox/CTBenchmarks.jl#24 (comment) |
|
PS. @PierreMartinon @0Yassine0 note that definition such the dynamics in the problem below (source here) will not generate in place code; the dynamics actually needs to be "inlined" inside
|
|
@PierreMartinon any progress? |
|
@jbcaillau @amontoison Still hunting for type unstabilities and allocations, but at least the getters are fine now ! Back to the whole inplace aspect, I am starting to wonder if it will change much: the function for the NLP constraints has already been inplace since basically the beginning, and the OCP functions are typically used as:
Seeing this, the destination for the OCP functions is already allocated in c, so do we really benefit from them being inplace ? Inplace version currently looks like
Am I missing something ? |
good, what did you do, in the end?
Er... precisely: julia> foo1(x) = begin
r = zeros(2); r = [x[1] + x[3], x[2]^2]; return r
end
foo1 (generic function with 1 method)
julia> foo2(x) = [x[1] + x[3], x[2]^2]
foo2 (generic function with 1 method)
julia> foo!(r, x) = begin
r[:] .= [x[1] + x[3], x[2]^2]
end
foo! (generic function with 1 method)
julia> let r = zeros(2)
x = [1., 2., 3.]
println(@allocated r = foo1(x))
println(@allocated r = foo2(x))
println(@allocated foo!(r, x))
end
160
80
80 |
|
Currently I get 15 + 15 + 18 allocs for inplace vs 16 + 17 + 20 allocs for out of place. But maybe this is due to the more general type problem with the functions themselves, ie the inplace should have 0 allocs and the out of place would still have a few ? Inplace: Out of place: Well, since it's still a bit better I guess we can move on to drop the out of place version as we discussed. |
|
Hi @ocots, @jbcaillau This means that we only accept
NB. we could make inplace the default for functional OCPs also, and eventually remove out-of-place OCPs completely at some point ? |
@PierreMartinon @ocots @gergaud it is actually possible but takes a rather deep revision of CTBase, abstract / fun API:
inplacewhen created, requesting then that every function providing dyn / cost / constraints) be inplaceOn a side note: more and more, I think that the functional API should be kept for internal use only.
The text was updated successfully, but these errors were encountered: