ChrisRackauckas
commented
3 months ago This is not a good test case for it. Or at least the title is not correct. Julia's dead code elimination is performed at the lock level. So if you want to determine what code is actually run you need to check the post optimization llvm. But llvm's dce is very robust so I would be surprised if there is a problem there.
Now your example would not dce because your code mutates a global and thus the compiler is not allowed to delete that as it would clearly change the code behavior. So your test case, if changed to not have a side effect, would get erased in the llvm layer
But finally, it isn't optimal to drop all of the observed in there and rely on dce. While it would make 0 difference in runtime, it could make a difference in compile time. It would be good to actually measure that and see if it's an noticable effect. Since dce is prior to the most expensive passes I would be surprised if that was the case though
ctessum
Describe the bug 🐞
I have a project that involves data loaders, basically reading large amounts of data from files and interpolating them into MTK models, for example here: https://data.earthsci.dev/stable/geosfp/. There are a lot of variables in the data files, and the system is set up to load all of them as equations, because it's hard to tell ahead of time which ones will be needed. However, when I run the model, it appears that all of the variables from all of the data files are being load and interpolated at each time step, rather than only the ones that need to be computed to calculate the state variables. This seems to be slowing things down—when I look at the CPU profile, almost all of the time is being spent on data loading.
Expected behavior
I would hope that the observed variables would be computed lazily, i.e. only when the value of the observed variable is required to compute the system state, or when it is queried by someone interating with the solution object.
Minimal Reproducible Example 👇
The code below creates an ODESystem with one state variable and one observed variable. The observed variable isn't related to the state variable at all, so it doesn't necessarily need to be evaluated to solve the problem.
There is also a counter
unnecessary_computations, which gets incremented whenever the equation to calculateyis evaluated. Since we don't need to knowyto solve the problem, any evaluations of the equation leading toyare unnecessary.Therefore, after solution,
unecessary_computationsshould equal 0, but instead it equals 9 in this case. Insol.stats, the number of function 1 evaluations is also 9, suggesting that the unnecessary computation is happening whenever the ODE function is being evaluated.Environment (please complete the following information):
using Pkg; Pkg.status()using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)versioninfo()This command gives an error but I'm using Julia version 1.10.
Additional context:
There is a larger-scale reproducer here: https://github.com/EarthSciML/EnvironmentalTransport.jl/blob/28b0749bd7c6457cfa00ec305a0485accc6a07f5/docs/src/advection.md