Closed winedarksea closed 12 months ago
Thank you! This seems like a great performance tweak. I do not immediately see any reason to use einsum
instead of swapaxes
. Originally the design goal was simply ensuring that all relevant methods use vectorized Numpy operations, but not exploring very thoroughly, which Numpy operations would be the fastest after the first working one was found.
Speculating about the performance: It can be critical which BLAS/LAPACK operation this eventually translates to under the hood of Numpy - and if the answer is "none" that's bad too. The swapaxes
version probably translates directly to a sequence of very efficient matrix multiplications where the LHS is stored in row-major and RHS in column-major order, while einsum
could fall back to a generic C loop.
I will runs some tests and merge this if there are no issues. May take a week or two since I'm currently a bit swamped.
I use your simdkalman in my AutoTS project, thanks for the work, it is excellent code. While running the scalene profiler on my code base it identified a possible performance improvement and suggested a speedup. The credit for this really goes to GPT v4.
I've tested the speedup and it is faster and functionally identical for my use case. I haven't necessarily tested this on your entire code bases range of inputs and outputs so there may be some hidden catch that I am unaware of.
simple speed comparison:
it's hard to quantify the bigger picture but it looks like it makes the function about 10% faster overall, in my use case