Chris Elrod

How do I run the example?

Watching `htop` during a multithreaded fit is interesting. When multithreaded, my CPU sits at 0%. Every now and then I see brief spikes of activity. My load average eventually dropped...

> i think the 'slow' part is that we are applying the operator to column vectors in `u` one at a time > > https://github.com/SciML/SciMLOperators.jl/blob/746c0d50a75067fae4121547a3c00bd4bbe27ce9/src/sciml.jl#L608-L610 You could try replacing that...

I meant delete `mul!`, replacing it with loops

No indexing, but `view`s are okay? We could have a special overload for certain types.

Locally, I tried using `@turbo` in one of the `mul!` functions in `sciml.jl`. Master: ```julia julia> @benchmark mul!($v, $T, $u) BenchmarkTools.Trial: 10000 samples with 1 evaluation. Range (min … max):...

The code would need dispatches set correctly to behave correctly as a function of input types. ```diff diff --git a/src/sciml.jl b/src/sciml.jl index 5291b1d..f482517 100644 --- a/src/sciml.jl +++ b/src/sciml.jl @@ -593,7...

I could prepare a PR, or someone else more familiar with all the dispatches needed to only funnel valid types to `@turbo` methods. The approach is simply to replace `reshape`...

I haven't upstreamed the changes. The major changes are on working with `NTuple{N,VecElement{T}}`s directly without type pirating, which is a big change. I believe that leads to better code whenever...

We're allocating over 10_000 times as much memory as needed for the returned objects: ```julia julia> sol2 = @time solve(fit_enprob; saveat = t_forecast); 717.090530 seconds (5.89 G allocations: 865.902 GiB,...