Rules: Room for Computational Efficiency Improvements?

[abpolym]

How optimized are the implemented rules? So for example using StaticArrays, in-place BLAS, avoiding inverses?

[abpolym]

Just to start the conversation, as an example I will reference the open issue #368 concerning the Continuous Transition rules and an open pull request #502 which uses fast in-place operations mul!, @inbounds use in loops, and fast preallocation with similar() to solve that issue.

With high likelihood there are more of these opportunities to drastically speed up computation lurking in the rules folder.

[abpolym]

Adding to that, FastCholesky.cholinv is actually not fast as noted in issues ReactiveBayes/FastCholesky.jl#21 and ReactiveBayes/FastCholesky.jl#26. So any use of cholinv instead of a faster alternative is bad, if computational speed is of upmost importance such as in real-time control of robotic systems. I think there was an issue discussing the ability to choose between safe and fast operations?

[bvdmitri]

So any use of cholinv instead of a faster alternative is bad

Do not necessarily agree. Alternatives might be faster but at the same time less stable to numerical errors and produce bizarre results (which is the whole reason why cholinv is slower now, its more stable and is guarding against numerical errors). Similar to python actually, where we force symmetricity of A by doing (A + A') / 2 instead

[bvdmitri]

I would rephrase you that using of any inverse is bad if the computational speed is of upmost importance. Better indeed to use linear solvers instead, as suggested by @Nimrais in the linked issues

[abpolym]

I will just link more open issues related to computational efficiency in this discussion for future reference:

• Add inplace mul! with StandardBasisVector ReactiveMP.jl#288
• Speed up backward message for Linearization ReactiveMP.jl#342
• The computations of rules for ContinuousTransition node can be improved ReactiveMP.jl#368