Integration with VectorizationBase.jl for mixed-precision and saturating intrinsics?
stillyslalom opened this issue · comments
LLVM provides access to some useful vectorized intrinsics (e.g. saturating arithmetic or http://0x80.pl/notesen/2018-10-24-sse-sumbytes.html#sadbw), and those are easy enough to add to VectorizationBase.jl, but some coordination will be needed before those intrinsics can be used to painlessly redo various Images.jl kernels/reductions with @avx.
Tagging in @chriselrod, who has a much better handle on how to wrestle with LLVM.
There is a plan to implement saturating operations for integer types in CheckedArithmeticCore and use them in this package. (#239)
WIP: https://github.com/kimikage/CheckedArithmetic.jl/pull/1/files
I was addressing a few performance issues before the release of Julia v1.6.0, so that plan has been on hold for a while, but I haven't really stopped.
However, there does not seem to be strong interest in the CheckedArithmetic package and I am not sure that the plan is really a good one.
On the LoopVectorization/VectorizationBase side of things, I think I'll define specialized methods for functions like + and muladd of the form:
@inline Base.:(+)(x::Vec{8,Int32}, y::Vec{16,Int16})::Vec{8,Int32}and then check destination types to define the accumulators, so that it can use the specialized intrinsics.
@kimikage if you're willing to define methods for Vec and VecUnroll, I could create VectorizationBaseCore.jl to move those type definitions there (without anything else) so that you can extend them.
VectorizationBase.jl itself has gotten heavy.
The benefit of this vs me defining VectorizationBase.saturated_add, etc, is that we then have a single method.
It won't really matter if someone @avxes a loop in which they wrote saturated_add as LoopVectorization can substitute CheckedArithmetic.saturated_add for VectorizationBase.saturated_add, but will if someone is calling foo, where foo is using CheckedArithmetic.saturated_add.
We are now talking about two orthogonal things: vectorization and overflow handling. (To be fair, though, I was the one who tied the latter to the former.)
I believe that having just a single definition (of the function name) for each arithmetic operations is a great advantage. The issue #239 aims to do exactly that. Although, it is debatable whether CheckedArithmeticCore.jl is really the best place for them to be defined, I think it is preferable to have those definitions in a package in JuliaMath rather than in JuliaSIMD.
We might want to ask for opinions on that in a place like the Discourse.
FixedPointNumbers has the same problem of not enough maintainers, but the development of VectorizationBase.jl and LoopVectorization.jl is expected to be discontinued.
https://github.com/JuliaSIMD/VectorizationBase.jl
https://github.com/JuliaSIMD/LoopVectorization.jl
CheckedArithmeticCore.jl has also stopped development, but I would have had the commit privileges.