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
I'm not sure if this is a bug or if this is indeed how it's supposed to be. But if it's the latter, then this would argue that you should always prefer ETDRK4 over RK4 when your timestep is fixed.
The text was updated successfully, but these errors were encountered:
Benchmarks are definitely a good idea --- this script is probably good enough. It may be better to use the native Diffusion model for benchmarks of the timestepping methods?
The difference between RK4 and ETDRK4 is that linear terms are explicitly calculated in RK4. This may involve a few extra arithmetic operations that account for the 5% difference in timing? 5% may be close to the accuracy of the benchmark, by the way, so its hard to tell if this is a real difference. I don't think many users would notice this difference. I'm happy to see that they are within 5% and that memory consumption is low. This is a good result in my opinion.
A trickier question is whether multithreading / manually written kernels might speed up these time-stepping routines, and whether we should implement it via KernelAbstractions. This benchmark is a good start.
Sometimes benchmarks will catch a bug that does not result in test failing but does result in considerable slowdown.
For example, playing around I figured that ETDRK4 time stepper is often faster than RK4.
I'm not sure if this is a bug or if this is indeed how it's supposed to be. But if it's the latter, then this would argue that you should always prefer ETDRK4 over RK4 when your timestep is fixed.
The text was updated successfully, but these errors were encountered: