You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I measured before, tableau-based methods were really really bad compared to hand-unrolled methods. But this was with Arrays and FixedSizeArrays. But now there's StaticArrays.jl, could it work?
The issue is that there's tons of specialization for a lot of the methods. Each of them "skip true zeros" in the tableaus (which, by the assumptions used to do the derivation, can be a lot in higher order methods). They have different error estimation schemes (DP8 and BS5 are good examples there). They have wildly different dense output schemes. Etc. So I don't know what we'll really get out of it because we'll still have to specialize a lot, but maybe it could be useful.
The text was updated successfully, but these errors were encountered:
SDIRKs and Rosenbrocks can probably use it too. The issue is that doing this will make it so that .= doesn't put as much in a single call, which will hurt immensely hurt GPU kernels.
When I measured before, tableau-based methods were really really bad compared to hand-unrolled methods. But this was with Arrays and FixedSizeArrays. But now there's StaticArrays.jl, could it work?
The issue is that there's tons of specialization for a lot of the methods. Each of them "skip true zeros" in the tableaus (which, by the assumptions used to do the derivation, can be a lot in higher order methods). They have different error estimation schemes (DP8 and BS5 are good examples there). They have wildly different dense output schemes. Etc. So I don't know what we'll really get out of it because we'll still have to specialize a lot, but maybe it could be useful.
The text was updated successfully, but these errors were encountered: