-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory allocation #9
Comments
It seems that, for the example above, most of the memory is allocated in Can I ask why not to use a package like ElasticArrays.jl for |
Because one of the bullet points of this package is that vectors don't need to be plain That being said, there is already some specialization for the case where the vectors are some I think, however, this is only useful once indeed your first point is addressed, supporting in-place linear operators. Myself, I would be fine with only supporting in-place/mutating linear maps |
The code is here: https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/utils.jl#L1-L27 Ignoring https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/utils.jl#L7-L12 as an old way for passing extra functions via dispatch, what this code does is it reads the current methods table and then returns a boolean if the number of arguments (for the maximum argument dispatch) is sufficiently large. Then that function is used to set a parameter of an inner constructor https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/problems/ode_problems.jl#L29-L31 or the user can set the parameter themselves to override the inplace checking, and that then ends up as a type parameter. Everything works off of the problem type as input, so from that point on everything is inferred by that. The inference isn't totally automatic because the Using the maximum of the number of arguments for all methods has seemed to work. Surprisingly, this is something that we haven't had any users open issues for, so while it's maybe not "Julian" to be taking a peak at the methods table, it's been very robust. |
@ChrisRackauckas , thanks for the detailed information. Checking the methods table was also what I had in mind, but I was not certain whether this was a sane approach. @nrontsis , another issue that I will certainly tackle at some point, though I will probably have different priorities the first month or so. Any attempts are welcome though. |
Thanks a lot for the very nice package.
Although it seems that your package is faster and more robust than
eigs
it allocates significantly more memory thaneigs
. For example, performing Arnoldi witheigsolve
on a1000 x 1000
matrix allocates ~20x more memory as compared toeigs
:while the number of iterations/matrix multiplications are comparable for the two functions.
On a related note, it would be nice to allow for functions
f(y, x)
that mutatey
.I am happy to contribute if you provide guidance.
The text was updated successfully, but these errors were encountered: